All of lore.kernel.org
 help / color / mirror / Atom feed
From: GrandMasterLee <masterlee@digitalroadkill.net>
To: mgross@unix-os.sc.intel.com
Cc: Austin Gonyou <austin@coremetrics.com>, linux-kernel@vger.kernel.org
Subject: Re: Using O(1) scheduler with 600 processes.
Date: 24 Jan 2003 00:08:00 -0600	[thread overview]
Message-ID: <1043388479.12855.21.camel@localhost> (raw)
In-Reply-To: <200301240204.h0O24Kr04239@unix-os.sc.intel.com>

On Thu, 2003-01-23 at 20:05, mgross wrote:
> You should definitely give it a try.
> 
> However; boosts in Oracle throughput by going to the O(1) scheduler may end 
> up being dependent on your I/O setup.
> 
> I was helping out with a TPCC benchmark effort last fall for Itanium Oracle 
> through put on Red Hat AS.  For the longest time the guys with the big iron 
> hardware would not move to the newer kernels with the O(1) scheduler.  They 
> had a silly rule of only accepting changes that improved TPCC throughput.  
> (oh, this work was on 4-way Itanium 2's with 32Gig of ram, and a large number 
> of clarion fiber channel disk array towers)

We've got LSI, so it's very similar.

> Anyway, for the longest time the old 2.4.18 kernel with the 4/10/04 ia-64 
> patch was 10% better than the a kernel with O(1) scheduler.  I never quite 
> figured out what the problem was.  I think the difference was in the way 
> Oracle likes to be on a Round Robbin scheduler, and the O(1) scheduler tended 
> to get unlucky more often than the old scheduler, for those drive arrays.
> 
> However; when we updated the clarion towers to have more drives and to 18K 
> RPM drives from the 15K drives, all of a sudden the O(1) scheduler beat the 
> the old scheduler.

Well, if I could get a clean patch against 2.4.20, or possibly some help
fixing the one  I do have, thanks to Ingo, then we'd have a straight
O(1) sched for 2.4.20. I tried merging the patch that Ingo gave me, and
everything seems OK, but I don't have any menu selection for O(1) stuff
in the kernel config.(0 and 100 priority bits)

So I can't tell if it's enabled. 


> Your milage will vary.
> 
> Give it a try.
> 
> --mgross
> 

I agree. In the interest of time, I may have to forego O(1), but maybe
I'll get lucky. :) *hint*hint* :)

TIA

--
GrandMasterLee

  reply	other threads:[~2003-01-24  6:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-24  0:10 Using O(1) scheduler with 600 processes Austin Gonyou
2003-01-24  0:24 ` Martin J. Bligh
2003-01-24  6:09   ` GrandMasterLee
2003-01-24  6:18     ` Martin J. Bligh
2003-01-24  6:27       ` GrandMasterLee
2003-01-24  6:48         ` Martin J. Bligh
2003-01-24  8:50           ` William Lee Irwin III
2003-01-24  2:05 ` mgross
2003-01-24  6:08   ` GrandMasterLee [this message]
2003-01-24 18:22     ` mgross
2003-01-24 21:44       ` GrandMasterLee
  -- strict thread matches above, loose matches on Subject: below --
2003-01-24  0:24 Perez-Gonzalez, Inaky

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=1043388479.12855.21.camel@localhost \
    --to=masterlee@digitalroadkill.net \
    --cc=austin@coremetrics.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgross@unix-os.sc.intel.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.