comments on KDE performance tips

[Alexander Kellett]

On Mon, Jan 13, 2003 at 09:26:33PM -0800, Andrew Morton wrote:
> Ingo did the original one.  I did another one (basically the same thing, more
> complete) for 2.4.

ingo's was scheduler latency only right?

> > more important to me was the i/o disk scheduler stuff
> > that went into 2.5,
> 
> hm, I seem to be largely to blame for that.  2.5 kernels are generally tons
> more responsive when under disk I/O load.

yay for read_latency2 :)    (in gentoo kernel also iirc)

> Man, I should start charging for this stuff.

if you're at linuxtag i'll buy you a beer :)

> It does.  Generally the O(1) scheduler improves responsiveness by a large
> amount when there is CPU-intensive work going on (eg: compiling things).  But
> occasionally it just gets it completely wrong and goes horrid.

thats mainly the stupid yield behaviour that staroffice has yes?
oh, and the fact that tasks magically become seen as batch occasionally.

umm... quick grep:
   arts/flow/gsl/gslcommon.c:     sched_yield ();
anyone know if gsl is used yet? i have to wonder why arts is using 1.9% cpu 
while it idles seems quite stupid to my puny brain.

> The CPU scheduler in 2.5.current is tons better than the one in RH8.0.  And
> Andrea Arcangeli's reworked O(1) scheduler is by far the best.  In the -aa
> kernels.

any chance of that getting into 2.5 at any point soon? has the patch
been seperated out or is the 0(1) quite far from the original version?
i've spent days reading the apple safari patches for khtml, maybe i'll
start on kernel patches now :)

> Nope.  I dispute that the low-latency patch or the preemptible kernel make a
> perceptible difference.  Because it is *extremely* rare for the kernel to
> hold off a context switch for longer than ten milliseconds.  And that is less
> than a monitor refresh interval.  So I don't think it makes any difference at
> all.

thats why i said "anal" and "as a person" (aka percieved)

;-)

> So there's almost twenty seconds worth of startup time here which could be
> shaved off by improving the IO access patterns.  This would require runtime
> analysis of the pagefault pattern, and re-layout of elf files based on that
> analysis.  Basically we want to pull each executable and shared library into
> pagecache in one great big slurp.

i'm correct in saying that the libs are mmap'ed and thus loaded on demand
via the pagefaults?, relayout of course would make the major difference
but from what i read here startup time is majorly dependant on seek time?
(i'll try an system oprofile of cold kde startup at some point this week)

could a logging module (or patch) be made for the kernel that logs all
pagefaults and their locations on disk? then, after system and kde startup
the module is switched off (hehe, unloaded, yipee) and the log sorted and
made optimal (i guess the kernel/elevator/readahead will do that, but some 
optimisation will decrease syscalls i guess) and on following startups a
a dd-like app which takes a block range list could be run and thus get
everything nice and warm. 

<sick>
   syscall (or whatever) for doing the logging, and for stopping the logging, 
   then all apps can stop the logging after they've been loaded and have
   drawn there main window.
</sick>

do stats come from the pagecache?, can you do multiple stats in one go? (aio?)

> I assume these applications are also reading zillions of little config, font,
> icon, etc files as well.  That'll hurt.  One possible way of speeding that up
> would be for the application to maintain its own cache (on-disk) of all the
> info which it needed to start itself up.  So on the second startup it can all
> be read in in a single swipe.  Obviously, information coherency is an issue
> here.

yup :( on-disk caches will probably end up getting corrupted and 
causing all sorts of app screwups with hellish debug problems.

Alex

-- 
"[...] Konqueror open source project. Weighing in at less than
            one tenth the size of another open source renderer"
Apple,  Jan 2003 (http://www.apple.com/safari/)