linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Daniel Phillips <phillips@arcor.de>
Cc: Rik van Riel <riel@conectiva.com.br>,
	Paolo Ciarrocchi <ciarrocchi@linuxmail.org>,
	linux-kernel@vger.kernel.org
Subject: Re: LMbench2.0 results
Date: Mon, 09 Sep 2002 09:52:09 -0700	[thread overview]
Message-ID: <3D7CD1B9.B1491E6@digeo.com> (raw)
In-Reply-To: E17oRCu-0006pL-00@starship

Daniel Phillips wrote:
> 
> On Monday 09 September 2002 15:37, Rik van Riel wrote:
> > On Sun, 8 Sep 2002, Daniel Phillips wrote:
> >
> > > I suspect the overall performance loss on the laptop has more to do with
> > > several months of focussing exclusively on the needs of 4-way and higher
> > > smp machines.
> >
> > Probably true, we're pulling off an indecent number of tricks
> > for 4-way and 8-way SMP performance. This overhead shouldn't
> > be too bad on UP and 2-way machines, but might easily be a
> > percent or so.
> 
> Though to be fair, it's smart to concentrate on the high end with a
> view to achieving world domination sooner.  And it's a stretch to call
> the low end performance 'slow'.

It's on the larger machines where 2.4 has problems.  Fixing them up
makes the kernel broader, more general purpose.  We're seeing 50-100%
gains in some areas there.  Giving away a few percent on smaller machines
at this stage is OK.  But yup, we need to go and get that back later.

> An idea that's looking more and more attractive as time goes by is to
> have a global config option that specifies that we want to choose the
> simple way of doing things wherever possible, over the enterprise way.

Prefer not to.  We've been able to cover all bases moderately well
thus far without adding a big boolean switch.

> We want this especially for embedded.  On low end processors, it's even
> possible that the small way will be faster in some cases than the
> enterprise way, due to cache effects.

The main thing we can do for smaller systems is to not allocate as much
memory at boot time.  Some more careful scaling is needed there.  I'll
generate a list soon.

  parent reply	other threads:[~2002-09-09 16:32 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-07 12:18 LMbench2.0 results Paolo Ciarrocchi
2002-09-07 12:27 ` Jeff Garzik
2002-09-07 18:53   ` Rik van Riel
2002-09-07 21:44     ` Alan Cox
2002-09-13 22:46       ` Pavel Machek
2002-09-07 14:33 ` James Morris
2002-09-09 22:22   ` Cliff White
2002-09-07 16:20 ` Andrew Morton
2002-09-07 20:03   ` William Lee Irwin III
2002-09-07 23:12     ` Andrew Morton
2002-09-07 23:01       ` William Lee Irwin III
2002-09-07 23:44       ` Martin J. Bligh
2002-09-08 17:07         ` Alan Cox
2002-09-08 18:11           ` Martin J. Bligh
2002-09-08 18:40           ` Andrew Morton
2002-09-08 20:48             ` Hugh Dickins
2002-09-08 21:51               ` Andrew Morton
2002-09-09 21:13             ` Alan Cox
2002-09-09 21:44               ` Andrew Morton
2002-09-09 22:09                 ` Alan Cox
2002-09-08  7:51     ` Andrew Morton
2002-09-08  7:37       ` David S. Miller
2002-09-08  8:28         ` William Lee Irwin III
2002-09-08  8:25           ` David S. Miller
2002-09-08  9:12             ` William Lee Irwin III
2002-09-08 20:02   ` Daniel Phillips
2002-09-09 13:37     ` Rik van Riel
2002-09-09 16:16       ` Daniel Phillips
2002-09-09 16:26         ` Martin J. Bligh
2002-09-09 16:55           ` Daniel Phillips
2002-09-09 17:24             ` Martin J. Bligh
2002-09-09 21:11             ` Alan Cox
2002-09-09 16:52         ` Andrew Morton [this message]
2002-09-07 12:40 Paolo Ciarrocchi
2002-09-07 14:09 Shane Shrybman
2002-09-07 18:04 Paolo Ciarrocchi
2002-09-13 22:49 ` Pavel Machek
2002-09-07 18:09 Paolo Ciarrocchi
2002-09-08  7:51 ` Andrew Morton
2002-09-14 18:26 Paolo Ciarrocchi
2002-09-15 18:08 ` Pavel Machek
2002-09-22 12:42 Paolo Ciarrocchi

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=3D7CD1B9.B1491E6@digeo.com \
    --to=akpm@digeo.com \
    --cc=ciarrocchi@linuxmail.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@arcor.de \
    --cc=riel@conectiva.com.br \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).