Harvard Business School of Echec - Tag - memory - Commentaires

ABI vs. API compatibility - Mart Raudsepp

Mart Raudsepp — Fri, 25 Apr 2008 21:10:11 +0200

err, yes, you need to implement PSS in all other platforms if you want to add it and not leave it empty for non-linux. Obviously. But you don't need to implement anything else already done yet again with the suggestion in comment #8...

ABI vs. API compatibility - Benoît Dejean

Benoît Dejean — Wed, 23 Apr 2008 11:11:02 +0200

Whenever i add a new functionnality (which is implemented as 3/4 functions), it has to be ported on linux, the 2 BSD arch and eventually solaris, darwin or aix. I can't do all these ports because of a lack of time/interest. So adding a new function for a single guint64 is too much work/breakage.

I was looking for alternatives where i would be able to do all the work myself:
- breaking the ABI moves all the work to distro packagers
- breaking the API would let me submit trivial patches to upstreams

ABI vs. API compatibility - Mart Raudsepp

Mart Raudsepp — Tue, 22 Apr 2008 23:22:30 +0200

Benoît> "Well, i cannot deprecate anything because that would mean throw away all the different/untested implemtentations on all !linux arch. Adding a new function also means breaking all !linux arch until someone test it (which almost always happens after the first stable release)."

How about adding the PSS support to the existing functions, but afterwards renaming glibtop_get_proc_mem to the new name, while adding a compatibility wrapper of the old name (keeping API and ABI in effect) that constructs the old style struct out of the results it gets from the new one that has more data - should be just some struct field copying and throwing away the bigger struct before returning the copied (deprecated) compatibility one from glibtop_get_proc_mem

ABI vs. API compatibility - Bronson

Bronson — Tue, 22 Apr 2008 21:32:40 +0200

I gotta agree with Rob... Leave this code alone, deprecate it, and just add a new call that takes a selector to tell what value to return.

Otherwise, you'll have to figure out hack upon hack upon hack every time you want to make this sort of change in the future. And, given kernel development, it won't be long before you'll need to extend it again...

ABI vs. API compatibility - James Henstridge

James Henstridge — Tue, 22 Apr 2008 17:22:04 +0200

If you decide to break the API, one option would be to add a "version" field to the start of the struct. Require the caller to fill it in before calling glibtop_get_proc_mem() so you can tell how big the caller thinks the struct is. Include the current version as a #define in the header so the caller can use it to initialise the structure to the right version.

If you need to expand the struct in the future, increment the version number and add new fields to the end. Then make glibtop_get_proc_mem() only fill in the fields if the version number is appropriate.

ABI vs. API compatibility - Benoît Dejean

Benoît Dejean — Tue, 22 Apr 2008 16:04:37 +0200

Well, i cannot deprecate anything because that would mean throw away all the different/untested implemtentations on all !linux arch. Adding a new function also means breaking all !linux arch until someone test it (which almost always happens after the first stable release).

Storing pointers is not an option because the struct may be marshalled across a pipe. And the marshalling code is already terribly broken.

Adding reserved members is very hard when you don't want to bloat your struct. I've already provisioned glibtop_cpu for 32 CPU, that makes sizeof ~ 2KiB.

ABI vs. API compatibility - Jeff Licquia

Jeff Licquia — Tue, 22 Apr 2008 15:04:22 +0200

You could start using symbol versioning, and provide both.

ABI vs. API compatibility - Mart Raudsepp

Mart Raudsepp — Tue, 22 Apr 2008 14:20:00 +0200

Looks like that duplicated guint64 could fit a pointer that could point to a new struct with more padding. However, I'm wondering what's the point of this public structure - wouldn't separate function APIs for a set of these be more ABI proof? if that's a good idea, could just not expose PSS in that struct at all and introduce some new API for this, say glibtop_proc_get_pss. Then again, I assume it's all retrieved in one go and that would reduce efficiency when one needs to call get_pss, get_rss and so on in a row?
If you need to stick with a struct, it might be a good idea to at some point introduce a new one that has some padding available for future expansion and a new function, say glibtop_get_proc_mem2 (yes, need a better name) that returns it, having library users that need PSS information convert to the API and depend on the new libgtop version.
Sorry, just thinking out loud, maybe something useful

ABI vs. API compatibility - Rob

Rob — Tue, 22 Apr 2008 14:06:55 +0200

Well, all these options are ABI breaking - the 'break the API' options also break ABI, just subtly. which is worse, as its not obvious to developers or package maintainers that something has changed.
IMHO, the best option is to deprecate glibtop_get_proc_mem and add a new function (say glibtop_get_process_usage or such) that takes a pid and an enum value for which field to return.

ABI vs. API compatibility - Murray Cumming

Murray Cumming — Tue, 22 Apr 2008 14:03:37 +0200

If it's this simple then you can just add a new function that returns a new struct, and deprecate (not break) the old one.

Unix 64bits fun - Jess Sightler

Jess Sightler — Sat, 05 Apr 2008 22:46:48 +0200

In my experience, 64bit Windows has been slow to get deployed even on the server as well. But that is changing rapidly. All of our new servers here have 64bit Windows, and I am starting to see a large number of new customer servers go that way as well.

Desktop users on the other hand have been much slower to come around.

Unix 64bits fun - troll

troll — Sat, 05 Apr 2008 22:01:28 +0200

I have to totally agree with you, but I have to clarify something. 32-bit Windows servers can use 3 or 3.5 gigabytes per process if you change the default settings slightly, depending on the edition you are using. It's not much of a help but it's something alright.

Unix 64bits fun - Bill Gates

Bill Gates — Sat, 05 Apr 2008 21:03:48 +0200

WTF, 4 GB SHOULD BE ENOUGH FOR EVERYONE!!!1!

bootparam mem=128M - Benoît DEJEAN

Benoît DEJEAN — Mon, 26 Nov 2007 09:09:29 +0100

I know that GNOME 2.6 would run almost fine with 128MiB. But that was years ago, i'm talking about 2.20.

bootparam mem=128M - Scott

Scott — Sun, 25 Nov 2007 22:14:50 +0100

My wife runs GNOME on a laptop with 128MB of RAM---she usually is running firefox and abiword on top of that!

bootparam mem=128M - mike

mike — Sun, 25 Nov 2007 21:21:15 +0100

Remind us on the 7th please

(and write a guide for newbies :D)

most import: disable your gnome-panels before logging in ^^

bootparam mem=128M - AdamW

AdamW — Sun, 25 Nov 2007 20:27:08 +0100

I ran GNOME on a P2/450 with 128MB of RAM full time from 2.4 to 2.12. It was slow, but generally worked fine.

bootparam mem=128M - Havoc

Havoc — Sun, 25 Nov 2007 18:55:50 +0100

Finishing just a short list of stuff might have a big impact: dconf/gsettings, gvfs, and nicer dbus-glib bindings including single instance app support. Those things are the last barriers to dropping big piles of old library code, and the people working on them could probably use help testing (and porting apps).

bootparam mem=128M - Philip

Philip — Sun, 25 Nov 2007 18:10:36 +0100

I've got Fedora 8 running on my old Amilo M laptop with 128MiB of RAM. I've removed the services I don't need as well as quite a few other processes, but I haven't had to be excessive in my pruning, and it does run OK (although definitely not brilliantly).

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Mon, 25 Jun 2007 11:32:36 +0200

No James, this isn't enough. I'm already doing it with git, and it just doesn't work. With this kind of work, you end up pushing again and again ... and upstream just can't merge.

we need distributed control system - James

James — Sun, 24 Jun 2007 13:38:34 +0200

You might want to use bazaar!

By installing the subversion bzr plugin, you can:

bzr clone http://path/to/svn

then when you want to merge, call

bzr pull

and to publish your changes

bzr push sftp://path/to/public/html

we need distributed control system - jmmv

jmmv — Thu, 21 Jun 2007 23:22:52 +0200

Jeff: It may be completely reasonable for *you* because you *already* have access to the repository. But those who don't (such as me) can really take advantage of a DVCS. You have to be on this side to understand the problems that arise; otherwise it's hard to explain. DVCS break the traditional "gain commit access" methodology, and all the elitism behind it. But anyway, and as Benoit already said, this is not the place to discuss whether DVCS are better or not.

we need distributed control system - Benoît Dejean

Benoît Dejean — Thu, 21 Jun 2007 23:18:23 +0200

Andrew > Thanks, stg is a very smart tool.

we need distributed control system - Jeff Waugh

Jeff Waugh — Thu, 21 Jun 2007 22:07:16 +0200

SVN is completely reasonable for a centralised mainline branch (and a project like GNOME does need a clear central mainline). With tools like git-svn and bzr-svn, it's very easy to branch into DVCS land and commit back to SVN. So, don't cry about GNOME's use of SVN -- use the tools that exist out there to make it work better for you!

we need distributed control system - Uzytkownik

Uzytkownik — Thu, 21 Jun 2007 16:36:52 +0200

I've never used git so I can't compare but bazaar (http://bazaar-vcs.org/) is great (it also have a svn plugin) - I prefere it over svn and cvs.

we need distributed control system - jmmv

jmmv — Thu, 21 Jun 2007 16:33:42 +0200

Murray: Sure the VCS cannot simplify the creation of big branches. But by using a DVCS it is extremely easy *for other people* to keep their personal branch in sync with the main one. It's not your job (as the maintainer) to do the syncing; it's the developers one. And with a DVCS it is much, much easier for them. Plus if you want (again, as the maintainer), you can merge the foreign branch (after a review, be it based on patches or whatever) and keep the *development history* for that foreign branch.

Let me suggest this talk about Git, given by Linus at Google: http://www.youtube.com/watch?v=4Xpn...

You have to be working "on the other side" (i.e. without access to the main project's repository) to really value the advantages of a DVCS.

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Thu, 21 Jun 2007 15:56:42 +0200

It's a myth that DVCS are harder to use. A DVCS is not a toy for angry kids like me. I'm not having that discussion, sorry that you don't understand all the opportunities brought by DVCS. I think SVN sucks.

we need distributed control system - Murray Cumming

Murray Cumming — Thu, 21 Jun 2007 15:35:41 +0200

> If someone wants to work a new feature, would you be
> OK if he would throw you a 10Kline patch

That doesn't happen very often. No VCS can make it easy to do big branches. Big branches are fundamentally difficult to merge.

When you do need to branch, I'm currently fairly happy with how svn does it. People have used bzr to branch from my svn, though I guess that doesn't make it so easy to merge back.

Most work is just small patches. I am very afraid of making life difficult for all those people, doing normal work, just because one or two people would like something that has a special feature.

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Thu, 21 Jun 2007 14:32:53 +0200

stgit looks fine, but svn + git-svn + stgit is too much.

Let's just switch to git. Moreover, managing patch is only good if you don't care about the revision log. A patch is the merge of all your work. On the other hand, when you merge, you get everything.

The problem is the upstream VCS and everyone seems to think that it's going to be solved by stacking again and again on the contributor side. This is just wrong. Managing patches feels quite stupid when you're used to use branch and do cherrypicking. cherrypicking makes patches useless i think.

we need distributed control system - Andrew Sutherland

Andrew Sutherland — Thu, 21 Jun 2007 13:51:02 +0200

Have you tried using stacked git? (stgit) It's like quilt for git, and allows you to work in a patch-centric way. Basically, your current 'state' in a stgit-managed branch is managed in a bunch of patches, which are then applied in series.

Any changes you make are applied to the top-most active patch in your 'stack' when you invoke 'stg refresh'. The revision history of each time you do a refresh is there too, and 'qgit' (the best git GUI I've seen) understands the patches and their intermediary state.

The result is that you are always breaking things up into patches as you would submit them in a single unified workspace. The other option I could think of (but don't have a lot of experience with) is having one branch or workspace per patch you would want to submit, merging things across between them as desired.

The one downside to stgit in my mind is that when you push/pop patches onto the active stack (or just re-order them), timestamps of affected files may change even if their contents do not, which will confuse most build systems...

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Thu, 21 Jun 2007 13:08:22 +0200

Murray > forking and branching are obviously not the same. I'am talking about how hard it is to merge when your VCS sucks at it. If someone wants to work a new feature, would you be OK if he would throw you a 10Kline patch ? And that guy would certainly quit because maintaining a 10K line patch against upstream is very very hard. Now it would be awesome if he could often pull/merge from upstream to update his new branch. In the end, to get the feature from upstream, you'd just have to pull from his branch. Or you could cherry-pick.

Jeff > git-svn does the opposite. And merging inside git-svn just blows the full revision history. And if everyone has to setup git-svn on his side, let's move to git/mtn/hg/etc

jmmv > I'm glad that you read that post. I was really thinking about your job. I know NetBSD has a patchset for GNOME. It's hard for you to maintain. And it's hard for me to get your patch. With DVCS, we could happily pull/merge/cherrypick from each other.

we need distributed control system - jmmv

jmmv — Thu, 21 Jun 2007 12:32:31 +0200

Wholeheartedly agreed. I, as a long-term maintainer of GNOME on NetBSD (not very active now, though), would really welcome a trivial way to maintain my portability fixes before they get integrated (which sometimes never happens, but that's another frustrating story). A DVCS could certainly simplify this.

Murray: It's OK if you want to see patches instead of a URL... it's the *tool* who should automatically be able to generate those patches. But the *developer* should be able to manage them more easily, and that is basically what a DVCS offers.

we need distributed control system - Jeff Schroeder

Jeff Schroeder — Thu, 21 Jun 2007 12:13:25 +0200

sudo apt-get install git-svn

we need distributed control system - Murray Cumming

Murray Cumming — Thu, 21 Jun 2007 12:07:26 +0200

If you were a contributor to my project, I'd want to see patches, not a URL of some fork of my project, even if the VCS made it relatively easy to merge.

And if it was my project, I'd rather not see you suggesting that people use a fork of it.

memory upgrade - K

Mon, 23 Apr 2007 08:31:31 +0200

you might be living in a cave dude, look around you maybe?

bash_completion - FU

FU — Sun, 22 Apr 2007 16:36:12 +0200

USE zsh!

memory upgrade - ken

ken — Sat, 21 Apr 2007 02:33:36 +0200

"I personally am switching to the desktop which uses the object oriented language"

There's a Smalltalk desktop?

memory upgrade - Benoît Dejean

Benoît Dejean — Fri, 20 Apr 2007 19:12:25 +0200

You may then want to open a bug against system-monitor.

bash_completion - anon

anon — Fri, 20 Apr 2007 19:09:09 +0200

bash_completion is broken by design.
It tries to parse itself at run time because it ignores the
complete -o plusdirs
option bash3, it tries to implement that by loading itself twice.
Barf.
Delete that stuff and the slowdown should be mostly gone.

memory upgrade - Bob

Bob — Fri, 20 Apr 2007 14:34:52 +0200

Me too ! Currently evolution -> Memory : 5.6MB

memory upgrade - Benoît DEJEAN

Benoît DEJEAN — Fri, 20 Apr 2007 14:09:04 +0200

I am talking about private_dirty + X server memory which is displayed in "Memory" column of system-monitor

memory upgrade - Bob

Bob — Fri, 20 Apr 2007 14:05:46 +0200

Depends if you count shared or not…

bash_completion - Marius Gedminas

Marius Gedminas — Fri, 20 Apr 2007 13:36:18 +0200

bash_completion also slows down the shell startup, which is noticeable when you open a new terminal and want to type straight away.

I've created a subset of /etc/bash_completion in ~ containing only the commands I need most.

memory upgrade - Benoît DEJEAN

Benoît DEJEAN — Fri, 20 Apr 2007 13:15:46 +0200

Bob > ahahahhaah. I don't know how you get your stats, but they are plain wrong...

bash_completion - plaes

plaes — Fri, 20 Apr 2007 11:50:23 +0200

10MiB?

memory upgrade - Bob

Bob — Fri, 20 Apr 2007 11:19:58 +0200

I hope that the GMAE project will lead us to a reduced memory usage. Am I dreaming ?

gnome-terminal 20MiB ? 2.2MiB with ten tabs
evo is just 6.3MiB
Tou've got an old GNOME version ? 2.14 ?

memory upgrade - Benoît DEJEAN

Benoît DEJEAN — Fri, 20 Apr 2007 11:08:50 +0200

This is about my laptop. I reboot it only for kernel upgrades. Having 300-400MiB of swap means constant disk trashing. There's nothing wrong with my computer : application just take to much memory. Many of my friends experience the same issues.

Come on, my iceweasel with no plugin, started a week ago and only a couple of tabs takes 114,3MiB privated_dirty. Evolution is 35MiB. Xorg 55MiB. liferea 30MiB. gnome-terminal 20MiB. Nautilus 7MiB. etc You just can't run this with 256MiB of RAM.

memory upgrade - Gilles Dartiguelongue

Gilles Dartiguelongue — Fri, 20 Apr 2007 10:35:48 +0200

Not sure what you are doing with your computer but even if I agree that running gnome with 256Mo of RAM is a little to low, 512 is largely enough for epiphany (~tabs), tracker, evolution, deskbar-applet, terms.

FYI, I'm running this on a PIII 500 with only 128Mo of swap (yes that means my box would die with your numbers :p).

memory upgrade - C

Fri, 20 Apr 2007 10:08:47 +0200

You're not alone with that kind of gnomish performance. There is one less reason to use gnome since it has grown too slow.
I personally am switching to the desktop which uses the object oriented language, it really can't be much slower than this. At least the features are not crippled down to someones grandma's level.

memory upgrade - Bob

Bob — Fri, 20 Apr 2007 09:04:32 +0200

"starting a new terminal now only takes 1s where it lasted up to 10s !"

There is something wrong with your computer ! It takes one second max to do this with my 512MB.

memory upgrade - Diego

Diego — Fri, 20 Apr 2007 00:16:52 +0200

You aren't serious, are you?

What the hell does eat so many memory? 1.25 GB is sure better than 512, but with 512 it shouldn't take 15 seconds to switch evolution functions...unless evolution is a memory pg, which it is But it's easier to switch from evolution than adding more ram.

memory upgrade - Eugenia

Eugenia — Thu, 19 Apr 2007 23:53:24 +0200

Hmm, I don't know what is wrong with your system, but you might want to reboot more often or something or check your mem usage in general for strayed processes... 512 MBs is enough for normal usage with Linux (and Windows, and OSX). That includes firefox, evolution, terminals, rhythmbox open at the same time, and occasionally some light OOo open at the same time too.

Up to last year I even ran Arch Linux at a 128 MBs laptop without major problems (1-2 apps open at the same time, optimized services), so I would imagine something heavier, like fedora/suse/ubuntu will do fine on a 512 MB machine. I have two laptops running ubuntu with 512 MBs each and they are fine...

evolution + bogofilter - Mikhail Zabaluev

Mikhail Zabaluev — Mon, 19 Feb 2007 10:22:22 +0100

Thanks Ritesh for the link above; I'm the author of that code. See, I thought that running Bogofilter was simple enough to just take a sample plugin in C and write up the executable launch code.
The plugin has also made it to Ubuntu.

evolution + bogofilter - Ritesh Khadgaray

Ritesh Khadgaray — Sun, 18 Feb 2007 16:54:29 +0100

evolution bogofilter plugin
http://people.altlinux.ru/~mhz/soft...

ps : a part of fedora extras.