Re: Extreme memory usage for gnome-panel related apps
- From: David Zeuthen <david fubar dk>
- To: Alan Cox <alan lxorguk ukuu org uk>
- Cc: "Nickolay V. Shmyrev" <nshmyrev yandex ru>, Martin Ebourne <lists ebourne me uk>, desktop-devel-list gnome org, jamie <jamiemcc blueyonder co uk>
- Subject: Re: Extreme memory usage for gnome-panel related apps
- Date: Sun, 02 Dec 2007 18:32:47 -0500
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]