Linux users want better desktop performance (Screw data. Prioritize code)

[Adam Jackson]

On Tue, 2009-02-17 at 16:15 -0500, Colin Walters wrote:

> Ok, I only skimmed his article initially, I thought his argument was
> basically that it's better for interactivity to have a smaller buffer
> cache than to (preemptively or not) page out application sections (be
> that text, or stack/heap).
> 
> Certainly in the default configuration, the heap can be paged out, no?
>  I think by "Prioritize code." he really means "whatever the app needs
> to respond to user input".
> 
> This is apparently not a new debate: http://kerneltrap.org/node/3000
> 
> Though big picture if you're swapping very much you've basically lost.
>  So the biggest wins here definitely involve fixing applications (like
> federico's work on image caching and jemalloc in Firefox, alex's
> recent blog about tracking down extra nautilus heap usage).

There have been a couple of other ideas along these lines that I've been
kicking around for a while.  I'm not taking credit, certainly these
aren't revolutionary, but I do think they'd be worthwhile.

* Memory pressure signal from the kernel.  If the kernel gets within
(say) 5% of needing to evict something from memory to satisfy an
allocation, it could mark some fd readable, and then apps could
voluntarily shrink their caches.  If the time to recreate from source is
less than the cost of swapping, this wins; think JPEG to pixmap
expansion cost here.

* Casual pixmaps in X.  Normally we have to hold on to pixel data come
hell or high water.  Firefox could reasonably create its pixmaps through
some other channel if it knew that it had the source data still to work
with; this would give X the ability to respond to the above pressure
signal sanely.

* Compressed image transport in X.  We did have this at one point but it
wasn't a big performance win in terms of raw drawing speed.  But for
memory pressure?  Maybe worth it.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-desktop-list/attachments/20090217/37ac83c5/attachment.sig>