Yet more "preloading"

[Lubos Lunak]

On Thursday 18 of March 2004 02:25, Oswald Buddenhagen wrote:
> On Wed, Mar 17, 2004 at 07:09:08PM +0100, Lubos Lunak wrote:
> > - where to do this caching. KDM (hello Ossi) and init.d script seem
> > the two places where this could be done, it takes some time to log in
> > using kdm, and there are definitely placed during init.d startup when
> > the HDD must be pretty bored. Ossi, could you please provide some
> > thoughts on this? I don't know how that works, and there could be two
> > places where to have this caching running, while typing in kdm, and
> > also while initializing X (at least it seem to be that while
> > initializing the graphics mode or whatever it's just waiting for about
> > two seconds and nothing is really happening).
>
> http://bugs.kde.org/show_bug.cgi?id=63789 :)
> the disadvantage of my envisaged approach is, that the preloading won't
> start before the greeter is up, and that will be only after the X server
> did "nothing" for a few seconds (and loading the greeter will be
> somewhat slower without the preload as well). it wouldn't be impossible
> to change that, though - only that some really "frontend-style" things
> (the user preselection) would have to move to the backend.
>
> the alternative is preloading kde unconditionally; this approach would
> make sense for kde-only systems/distributions. for that, a separate
> init.d script would be the cleanest solution, i think.
> i think this solution is more effective (and "simpler" for me (read: a
> no-op :)), but it looks even more like a hack (hard-wiring something is
> usually no good ... in any case it must be a yast/debconf/... option).

 My idea how this should work is roughly this (the perfect world version 
first):

- The scan utility is started somewhere in /etc/init.d/, gets all the paths to 
scan, and starts scanning them in the priority order given. Sadly, I don't 
think there's any way of specifying idle priority, even nice 20 still gets a 
small share of CPU time, and in fact 'nice -n 20 find /' can badly kill 
overall performance. This means that the scan process will have to be 
SIGSTOP-ed and SIGCONT-ed (or maybe better SIGUSR1/2, so it can quit itself 
on timeout in case something goes wrong). In reality suspending and 
restarting it while init.d scripts are run will be maybe pretty difficult, 
with parallel scripts (init.d startup sequence however right now sucks, at 
least on SUSE, as Dirk pointed out, as there could be such idle places). We 
will simply provide scripts/binaries/whatever and distributions may put them 
wherever they want.

- As soon as KDM core (backend, or whatever it is called) is started, it 
checks for the scan process, and if it's not running, it starts it. While 
loading the actual greeter GUI it suspends it temporarily, restarts again 
while waiting for user actions. As soon as it knows the username, it can add 
$KDEHOME paths to the scan (is there anybody paranoid enough to consider this 
a security problem?). Before KDM actually starts the session, it kills the 
scan. If the scan finishes, perhaps KDM could also try to preload the actual 
binaries (i.e. what my madvise preload hack did).

- KDM will remember which sessions it started recently, so if out of the last 
5 sessions 4 were KDE and one FVWM, it's clear precaching KDE makes sense, 
while the other way around it's not that clear (on the other hand ... the 
machine would be bored then ;)  ). I'm not sure how exactly the 'default' 
session would be handled, as that can start anything - perhaps KDM should 
remember this one as unknown and startkde later will change the record to 
KDE.

 Does that make sense? The init.d part maybe looks a bit complicated, but it 
is not really harder than the KDM part, and it'd be up to the distros to 
where to put it and where to resume/suspend it (it'd help if it could be 
started as idle-only priority). I'm not quite sure about the possible 
drawbacks, but hey, let's optimize for the common case of running KDE :).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/