[lkml]   [2002]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.5.34-mm4
Rik van Riel wrote:
> On Sun, 15 Sep 2002, M. Edward Borasky wrote:
> > Borasky's Corollary 1: If you *can* measure it and it *does* exist, the
> > cheapest solution may still be to buy more memory, more disks or a
> > faster processor.
> Current 2.5 is sluggish on systems with a fast CPU and 768 MB
> of RAM, whereas current -ac runs the same workload smoothly
> with 128 MB of RAM.

I've been running 2.5 on my desktop at work (800MHz/256M UP) since
2.5.26 and on the machine at home (Dual 850MHz/768M) on-and-off
(recent freizures sent that machine back to Marcelo; need to try
again). I also ran 2.4.19-ac-something for a couple of weeks.

Impressions are:

- 2.5 swaps a lot in response to heavy pagecache activity.

SEGQ didn't change that, actually. And this is correct,
as-designed behaviour. We'll need some "don't be irritating"
knob to prevent this. Or speculative pagein when the load
has subsided, which would be a fair-sized project.

- In both -ac and 2.5 the scheduler is prone to starving interactive
applications (netscape 4, gkrellm, command-line gdb, others) when
there is a compilation happening.

This is very, very noticeable; and it afects applications which
do not use sched_yield(). Ingo has put some extra stuff in since
then and I need to retest.

- In -ac, there are noticeable stalls during heavy writeout. This
may be an ext3 thing, but I can't think of any IO scheduling
differences in -ac ext3. I'd be guessing that it is due to
bdflush/kupdate lumpiness.

Overall I find Marcelo kernels to be the most comfortable, followed
by 2.5. Alan's kernels I find to be the least comfortable in a
"developer's desktop" situation.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.078 / U:7.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site