User bus conclusion

[Thiago Macieira]

On Wednesday, 10 de November de 2010 20:34:48 Lennart Poettering wrote:
> OK, so I log in twice, arrange my applets, and then log out of both, and
> everything I configured on the first login is completely lost? That's
> what I call broken.

I don't know. I haven't tried. BTW, it's the same case as two sessions running 
on the same NFS $HOME, so if this is an issue with the application (any 
application), the fixing has nothing to do with D-Bus.

Anyway, this has gone far too off-topic, so I'm not replying to this section of 
the thread anymore.

> > Ok, that's the first I'm hearing of that. I believe we must create a
> > separate discussion on this. Have you engaged anyone from KDE and other
> > DEs to discuss this?
> 
> I mentioned this briefly to some KDE folks as OSC. However before we can
> start the conversations with the KDE people we needed to make our own
> mind up. I think the key folks in the systemd and GNOME scene now have
> mostly agreed on something here, at LPC/GS. However only parts of that
> are implemented so far, so we don't know whether that'll fly in the end.

Ok. When there's something concrete that you want to discuss, let me know and 
I'll find you the right people to talk to.

> > It might be, but it's solving a problem that isn't solved elsewhere.
> 
> No, it's working around a problem that should be solved at the right
> place.

Ok, you can put it that way.

> systemd initializes, loads service data, begins to fork off
> processes. These forked off processes became COW copies of the systemd
> process, and use dlopen() to jump into some app code. systemd continues
> to run, changes a variable here and there and everywhere, since it goes
> on with start-up. Now, since a forked app is a COW clone of the parent
> every single page the parent processes accesses needs to pagefault. That
> is slow and ridiculous since you end up copying memory for no purpose at
> all: the child actually doesn't even have the slightest interest in the
> memory copied. Now multiply that by every single app you spawn this way.
>
> Hence, basically, systemd will always run into page faults, for every
> single page it writes to, a gazillion of times, since we forked of a
> gazillion of processes. And all the processes forked off will slowly
> duplicate the original systemd memory set in their own processes even
> though they don't even have the slightest interest in the actual data.
[snip]

I see your point. I hadn't thought of that.

> It's just a bad idea. Fix exec(), fix ld.so. Don't work around it!

Would love to see that happen. So prelinking helps here? No counter-
indications to prelinking? I'll be sure to pass on the recommendation.

Is there a runtime prelinking, when the system starts? That would have the 
same benefits of the fork-dlopen solution without the drawbacks.

> > It's not designing for broken drivers. It's working around the
> > stubbornness of NVidia, by saving our users tens of megabytes of memory
> > used, plus load-time relocations. It only takes 7 processes that need to
> > do OpenGL to consume 100 MB of memory. libnvidia-glcore.so.256.44 has
> > 395613 relative relocations out of 402050 total relocations.
> 
> Well, however that may be. On GNOME we actually try to do things
> properly. Not just work-arounds.

Yet NVidia still ships non-PIC libraries, which means GNOME users can't run 
more than a couple GL-enabled applications, at the risk of using too much 
memory. So much for idealism.

I agree we need a proper solution. But in the absence of one, I'll gladly 
accept a workaround.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20101111/1bf808cf/attachment.pgp>