Re: Extreme memory usage for gnome-panel related apps

[David Zeuthen <david fubar dk>]

On Sun, 2007-12-02 at 22:49 +0000, Alan Cox wrote:
> > (FWIW, personally, I'd like to see all of our service daemons (g-p-m,
> > g-v-m, pk-update-client, etc.) all sharing the same process space.
> > Things like that.)
> 
> With a kernel hat on do you have a specific reasons for that ? Is there
> stuff you gain or is this primarily about memory usage of non shared
> objects ?

I was thinking only performance wins: Most of these daemons poke system
components through D-Bus and listen for async events; by pooling the
traffic onto the same D-Bus connection some overhead may be saved
including only having to wake up a single process, only set up a single
connections and so forth.

Thinking more about it I'm not sure it matters much...

Then there's also the social aspect; if all our service daemons are in
the same process / code base (and perhaps written in similar ways using
similar patterns) it becomes easier to figure out how to add new
functionality. Also, the individual daemons can use non-IPC constructs
to talk to each other; for example there's a bunch of IPC between the
screensaver and the power manager; that could all be local [1]. Similar,
the volume manager refuses to mount anything if the screen is locked
[2].

     David

[1] : though there's the complication that the screensaver needs to be
more secure than most other service daemons. Then again it could use a
helper to do the critical bits like locking the screen (if it doesn't
already).

[2] : to prevent an attacker from walking up to a locked machine and
taking control of the machine by using a carefully crafted USB stick
that will cause a buffer over flow in a file system driver.