Comments on: Eternal Vigilance!

By: antistress

antistress — Fri, 27 Feb 2009 09:23:52 +0000

i’m using the Ubuntu Netbook Remix (UNR) launcher which means that i don’t use the desktop to display icons nor volumes etc.
I only display the panel, the wall paper and the UNR launcher

Is there a setting to configure to decrease memory use in that specific case ?

By: Ka-Hing Cheung

Ka-Hing Cheung — Fri, 20 Feb 2009 04:37:05 +0000

Well, even if I only use gedit to edit large files, it won’t be noticeable if those allocations are done with mmap. That was the argument I was trying to make.

By: alexl

alexl — Thu, 19 Feb 2009 14:35:41 +0000

Well, i guess there is a risk of heap fragmentation in gedit if its using the heap for large files…. So perhaps gedit is a good target for something like this. Would need some testing though.

By: alexl

alexl — Thu, 19 Feb 2009 14:33:04 +0000

Ka-Hing:

When the 1mb file is freed that would bump the mmap threshold. However, i don’t think this is a bad idea. It generally means you’re editing large files in your editor, and thus its not a bad idea to allocate these on the heap. After all, gedit is not a long-running background thing like nautilus, and while its in use its not a large problem if it uses the memory it requires.

I guess if you load one large file, close it and then keep gedit around for a long time while only loading small files there would be some memory not returned to the os. (Although it would just be swapped out, so its not a huge issue.) But i’m not sure this is the normal case when using gedit.

By: Ka-Hing Cheung

Ka-Hing Cheung — Thu, 19 Feb 2009 03:43:47 +0000

alexl: Yes I understand why that change was made. My comment was pointing out that many desktop applications are not performance sensitive (and even fewer have big allocations in the hot path), so making such a change _may_ save memory while not negatively affecting users in a noticeable way.

Applications that can take user inputed file sound like they would benefit, for example if I open a 1MB file with gedit it would bump the mmap threshold to at least 1MB (to hold the content). While it’s true that the user can always restart them it’s less than ideal.

By: Marius Gedminas

Marius Gedminas — Wed, 18 Feb 2009 20:35:44 +0000

On my system gnome-panel needs more memory than nautilus, which seems strangely reversed. And this doesn’t include the memory of various applets, of which multiload-applet alone accounts for 30 megs of RSS.

By: mati

mati — Wed, 18 Feb 2009 15:04:22 +0000

Awesome work!

> I noticed the other day that it seemed to be using a lot of memory again
It would be better if Gnome tracked its’ memory usage (and startup time) on a daily basis (AFAIR Mozilla does it). That way, regressions could be tracked and fixed right after they happen.

By: alexl

alexl — Wed, 18 Feb 2009 13:00:30 +0000

Milan:

The mmap treshold I set should be ok for nautilus as a whole. No need to keep the dynamic threshold for that.

I don’t know exactly what you mean by using another allocator for the background pics. The allocations happen in the standard pixbuf loader code, there is no way to make that use a special allocator. And using a special allocator for all pixbufs is not a good idea, as what is good for this specific case may not be good for others.

By: Milan

Milan — Wed, 18 Feb 2009 11:12:59 +0000

Quite interesting, thanks!

Wouldn’t this issue be worth a specific allocation method that you would use for backgrounds? I mean: keep the glibc optimized behavior for everything but background pics. Maybe you could gain more memory, and it could possibly be used by other apps.

Just my two cents…

By: alexl

alexl — Wed, 18 Feb 2009 08:41:54 +0000

ka-hing:

I’m not sure i follow. The glibc behaviour was changed so that apps would get better performance, as the costs of mmap is higher that what it used to be for various reasons (see the code). I don’t think desktop applications in general would perform better with this change, rather the reverse (i.e. perform worse).

The behavour in the nautilus case in kinda special for two reasons:
1) It has a single very short time where it uses much memory but then doesn’t
2) Its a long lived background process where its important that we’re not wasting memory when not in use

There might be other applications which happen to trigger similar bad behaviour from the dynamic threshold decision algorithm, in particular gnome-settings-daemon might be interesting to look at. However, we certainly don’t want to always do this without analysis.