Re: Desktop Kernel Stuff

[Michael Meeks <michael ximian com>]

Hi Alan,

On Fri, 2003-07-11 at 10:46, Alan Cox wrote:
> > 	There are several potential solutions; probably the best is the kernel
> > tracking / recording per-process disk access patterns, and doing more
> > intelligent, speculative, batch elevated read-ahead - if that makes any
> > sense.
> 
> Some work is being done there - its actually not very easy. Preloading
> binaries on big machines is one approach

	Interesting; having had this as a pipe-dream of things to poke at in
the kernel - is there a good place to read more (patches etc.) on that ?

> > 	Also - on the swap side; better paging - not knowing how the algorithm
> > works (and being none the wiser for having read the docs) - I'll waffle:
> > It seems that a more chunky approach for page recovery geared with
> 
> Chunkiness is configurable actually.
> 	echo "value" >/proc/sys/vm/page_cluster
> Where we cluster 1<<value pages per swap read/write

	Interesting - I can poke at that setting in the kernel too; what most
concerned me (from my very fast / sketchy) read of the VM docs - was
that it appeared that paging out blocks penalised all processes equally;
if so - that's perhaps a difference to the desktop, where aggressively
pruning a big swathe from a single process whence it can be recovered in
a similarly huge chunk may have better properties given our typical
use-case ?

> > 	Simply recognising and optimising for the use-case of a series of
> > single process being run for several minutes before switching to another
> > single process, rather than myriad interleaved concurrent transactions
> > all of which have to be fairly balanced would be most useful.
> 
> The interesting thing is that isnt what you actually see. The system does
> tend to optimise for that anyway, its trying to keep data around that you
> are using, which means it will tend to keep the pieces being used of the
> app you are using mainly.

	Sure - this is good; the problem being that when I switch from galeon
to evolution, and suddenly I need another 8000 pages exchanged to/from
disk - they have been pushed out by slow attrition and are thus nicely
scattered all over the disk :-)

> Some of the results on low memory boxes go back to the X server behaviour
> and whether you should always keep display buffers (moving a window tends
> to bring each app into RAM to scribble rectangles). Another is the amount
> of stuff Gnome seems to be doing during startup which does want measuring.
> On my boxes I'm seeing cpu idle, disk idle and completely idle patches.
>
> XFce + rox starts in about 3 seconds (from X cursor appearing to ready).

	Right - and we should be able to do the same. Can you give more
information on that breakdown of login resource usage ? the completely
idle patch must be Network related - I recently fixed a particularly
stupid redundant hostname reverse-lookup in bonobo-activation; I've just
pushed a fixed stable package:
http://www.gnome.org/~michael/bonobo-activation-2.2.3.tar.gz until
ftp.gnome.org updates - that fixes that silly; could that be the cause ?
or is there some other network related silly ? [ or is someone really
doing a sleep (10); in there :-].

	Thanks muchly,

		Michael.

-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot