All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin Gonyou <austin@digitalroadkill.net>
To: linux-kernel@vger.kernel.org
Subject: 2.4 Kernel Perf discussion [Was Re: [BUG] 2.4 VM sucks. Again]
Date: 24 May 2002 13:29:30 -0500	[thread overview]
Message-ID: <1022264970.10464.12.camel@UberGeek> (raw)
In-Reply-To: <435570000.1022263849@flay>

On Fri, 2002-05-24 at 13:10, Martin J. Bligh wrote:
> > Also, adjusting the bdflush parms greatly increases stability I've found
> > in this respect.
> 
> What exactly did you do to them? Can you specify what you're set to
> at the moment (and anything you found along the way in tuning)?

I actually changed the defaults of the bdflush parms before compiling. I
don't have that info right now because I had to dismantle my system in a
hurry, was a try-buy from Dell at the time, and we weren't authorized to
buy yet.

At any rate, I found, at the time, (2.4.17-pre5-aa2-xfs I think), that
the defaults for bdflush when running dbench would just *destroy* the
system. Changing the bdflush parms to be about 60% full, and flushing to
30%, while potentially wasteful, was indeed an improvement. 

IOzone benchmarks also show distinct improvements in this regard as
well, but I never had such terrible kswapd/bdflush issues with that test
as I did with dbench, to begin with. 

The test system was a Dell 6450 with 8GB ram and P3 Xeon 700Mhz 2MB
cache procs. I expect far greater peformance from the P4 Xeon 1.6GHz 1MB
Cache procs though. In that scenario, we will only be using 4GB ram
probably. That test will be internal to us and should start in the next
couple weeks (I hope). I'll be charged with making the system testing as
immaculate as possible so we have crisp information to use in our
decision making process as we move from Sun to x86.

> > Problem is, my tests are *unofficial* but I plan to do something perhaps
> > at OSDL and see what we can show in a max single-box config with real
> > hardware, etc. 
> 
> Great stuff, I'm very interested in knowing about any problems you find.
> We're doing very similar things here, anywhere from 8-32 procs, and
> 4-32Gb of RAM, both NUMA and SMP.

As soon as I can get time on their systems to do 4/8-way testing, I'll
make my benches available. Should be good stuff. :)

> Thanks,
> 
> Martin.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2002-05-24 18:29 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-23 13:11 [BUG] 2.4 VM sucks. Again Roy Sigurd Karlsbakk
2002-05-23 14:54 ` Martin J. Bligh
2002-05-23 16:29   ` Roy Sigurd Karlsbakk
2002-05-23 16:46     ` Martin J. Bligh
2002-05-24 10:04       ` Roy Sigurd Karlsbakk
2002-05-24 14:35         ` Martin J. Bligh
2002-05-24 19:32           ` Andrew Morton
2002-05-30 10:29             ` Roy Sigurd Karlsbakk
2002-05-30 19:28               ` Andrew Morton
2002-05-31 16:56                 ` Roy Sigurd Karlsbakk
2002-05-31 18:19                   ` Andrea Arcangeli
2002-06-18 11:26             ` Roy Sigurd Karlsbakk
2002-06-18 19:42               ` Andrew Morton
2002-06-19 11:26                 ` Roy Sigurd Karlsbakk
2002-07-10  7:50             ` [2.4 BUFFERING BUG] (was [BUG] 2.4 VM sucks. Again) Roy Sigurd Karlsbakk
2002-07-10  8:05               ` Andrew Morton
2002-07-10  8:14                 ` Roy Sigurd Karlsbakk
2002-08-28  9:28             ` [BUG+FIX] 2.4 buggercache sucks Roy Sigurd Karlsbakk
2002-08-28 15:30               ` Martin J. Bligh
2002-08-29  8:00                 ` Roy Sigurd Karlsbakk
2002-08-29 13:42                   ` Martin J. Bligh
2002-08-30  9:21                     ` Roy Sigurd Karlsbakk
2002-08-30 17:19                       ` Martin J. Bligh
2002-08-30 18:49                         ` Andrew Morton
2002-05-24 15:11     ` [BUG] 2.4 VM sucks. Again Alan Cox
2002-05-24 15:53       ` Martin J. Bligh
2002-05-24 16:14         ` Alan Cox
2002-05-24 16:31           ` Martin J. Bligh
2002-05-24 17:30             ` Austin Gonyou
2002-05-24 17:43               ` Martin J. Bligh
2002-05-24 18:03                 ` Austin Gonyou
2002-05-24 18:10                   ` Martin J. Bligh
2002-05-24 18:29                     ` Austin Gonyou [this message]
2002-05-24 19:01                       ` 2.4 Kernel Perf discussion [Was Re: [BUG] 2.4 VM sucks. Again] Stephen Frost
2002-05-27  9:24               ` [BUG] 2.4 VM sucks. Again Marco Colombo
2002-05-27 22:24                 ` Austin Gonyou
2002-05-27 23:08                   ` Austin Gonyou
2002-05-27 11:12       ` Roy Sigurd Karlsbakk
2002-05-27 14:31         ` Alan Cox
2002-05-27 13:43           ` Roy Sigurd Karlsbakk
2002-05-23 16:03 ` Johannes Erdfelt
2002-05-23 16:33   ` Roy Sigurd Karlsbakk
2002-05-23 22:50     ` Luigi Genoni
2002-05-24 11:53       ` Roy Sigurd Karlsbakk
2002-05-23 18:12 ` jlnance
2002-05-24 10:36   ` Roy Sigurd Karlsbakk
2002-05-31 21:21     ` Andrea Arcangeli
2002-06-01 12:36       ` Roy Sigurd Karlsbakk

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=1022264970.10464.12.camel@UberGeek \
    --to=austin@digitalroadkill.net \
    --cc=linux-kernel@vger.kernel.org \
    /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.