All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "M. Edward Borasky" <znmeb@aracnet.com>,
	Axel Siebenwirth <axel@hh59.org>,
	Con Kolivas <conman@kolivas.net>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, lse-tech@lists.sourceforge.net
Subject: Re: 2.5.34-mm4
Date: Sun, 15 Sep 2002 11:55:21 -0700	[thread overview]
Message-ID: <3D84D799.557653C7@digeo.com> (raw)
In-Reply-To: Pine.LNX.4.44L.0209151452560.1857-100000@imladris.surriel.com

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.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@digeo.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "M. Edward Borasky" <znmeb@aracnet.com>,
	Axel Siebenwirth <axel@hh59.org>,
	Con Kolivas <conman@kolivas.net>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, lse-tech@lists.sourceforge.net
Subject: Re: 2.5.34-mm4
Date: Sun, 15 Sep 2002 11:55:21 -0700	[thread overview]
Message-ID: <3D84D799.557653C7@digeo.com> (raw)
In-Reply-To: Pine.LNX.4.44L.0209151452560.1857-100000@imladris.surriel.com

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

  reply	other threads:[~2002-09-15 18:34 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-14  4:06 2.5.34-mm4 Andrew Morton
2002-09-14  4:06 ` 2.5.34-mm4 Andrew Morton
2002-09-14  4:01 ` 2.5.34-mm4 Rik van Riel
2002-09-14  4:01   ` 2.5.34-mm4 Rik van Riel
2002-09-15 10:50 ` 2.5.34-mm4 Axel Siebenwirth
2002-09-15 10:50   ` 2.5.34-mm4 Axel Siebenwirth
2002-09-15 14:31   ` 2.5.34-mm4 Rik van Riel
2002-09-15 14:31     ` 2.5.34-mm4 Rik van Riel
2002-09-16 18:33     ` 2.5.34-mm4 Bill Davidsen
2002-09-16 18:33       ` 2.5.34-mm4 Bill Davidsen
2002-09-15 17:41   ` 2.5.34-mm4 Andrew Morton
2002-09-15 17:41     ` 2.5.34-mm4 Andrew Morton
2002-09-15 17:36     ` 2.5.34-mm4 Rik van Riel
2002-09-15 17:36       ` 2.5.34-mm4 Rik van Riel
2002-09-15 17:39     ` 2.5.34-mm4 Rik van Riel
2002-09-15 17:39       ` 2.5.34-mm4 Rik van Riel
2002-09-15 17:49       ` 2.5.34-mm4 M. Edward Borasky
2002-09-15 17:49         ` 2.5.34-mm4 M. Edward Borasky
2002-09-15 17:54         ` 2.5.34-mm4 Rik van Riel
2002-09-15 17:54           ` 2.5.34-mm4 Rik van Riel
2002-09-15 18:55           ` Andrew Morton [this message]
2002-09-15 18:55             ` 2.5.34-mm4 Andrew Morton
2002-09-15 18:56             ` 2.5.34-mm4 Rik van Riel
2002-09-15 18:56               ` 2.5.34-mm4 Rik van Riel
2002-09-16  1:33               ` 2.5.34-mm4 Alan Cox
2002-09-16  1:33                 ` 2.5.34-mm4 Alan Cox
2002-09-16  2:32                 ` [PATCH](1/2) rmap14 for ac (was: Re: 2.5.34-mm4) Rik van Riel
2002-09-15 19:10             ` [Lse-tech] Re: 2.5.34-mm4 Andi Kleen
2002-09-15 19:10               ` Andi Kleen
2002-09-16 18:51               ` Bill Davidsen
2002-09-16 18:51                 ` Bill Davidsen
2002-09-19  9:01                 ` Jens Axboe
2002-09-19  9:01                   ` Jens Axboe
2002-09-16 18:48             ` 2.5.34-mm4 Bill Davidsen
2002-09-16 18:48               ` 2.5.34-mm4 Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D84D799.557653C7@digeo.com \
    --to=akpm@digeo.com \
    --cc=axel@hh59.org \
    --cc=conman@kolivas.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=riel@conectiva.com.br \
    --cc=znmeb@aracnet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.