All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	Nicholas Miell <nmiell@comcast.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.23
Date: Fri, 12 Oct 2007 08:21:59 -0400	[thread overview]
Message-ID: <470F66E7.7010509@tmr.com> (raw)
In-Reply-To: <20071012054615.GA22256@elte.hu>

Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>> ;) I think you snipped the important bit:
>>
>> "the peak is terrible but it has virtually no dropoff and performs 
>> better under load than the default 2.6.21 scheduler." (verbatim)
> 
> hm, i understood that peak remark to be in reference to FreeBSD's 
> scheduler (which the FreeBSD guys are primarily interested in 
> obviously), not v2.6.21 - but i could be wrong.
> 
> In any case, there is indeed a regression with sysbench and a low number 
> of threads, and it's being fixed. The peak got improved visibly in 
> sched-devel:
> 
>   http://people.redhat.com/mingo/misc/sysbench-sched-devel.jpg
> 
> but there is still some peak regression left, i'm testing a patch for 
> that.
> 
There's one important bit missing from that graph, the 
2.6.23-SCHED_BATCH values. Without that we can't tell how much 
improvement is from sched-devel and how much from SCHED_BATCH. Clearly 
2.6.23 is better than 2.6.22.any in this test, the locking issues seem 
to dominate that difference to the point that nothing else would be 
informative.

This weekend I have to do some building of kernels for various machines, 
so I intend to run some builds SCHED_BATCH and some will just run. If I 
find anything interesting I'll report.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot


  parent reply	other threads:[~2007-10-12 12:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-09 20:54 Linux 2.6.23 Linus Torvalds
2007-10-10  6:12 ` Nicholas Miell
2007-10-10 10:14   ` Ingo Molnar
2007-10-11  1:20     ` Nicholas Miell
2007-10-11  2:34     ` Zhang, Yanmin
2007-10-11 13:32       ` Ingo Molnar
2007-10-11  9:16     ` Nick Piggin
2007-10-12  5:46       ` Ingo Molnar
2007-10-11 14:15         ` Nick Piggin
2007-10-12 12:21         ` Bill Davidsen [this message]
2007-10-10  7:44 ` René Rebe
2007-10-10  8:37   ` Alexey Dobriyan
2007-10-10  9:12     ` Michael Tokarev
2007-10-10 10:36       ` Alexey Dobriyan
2007-10-10 10:53         ` Jan Engelhardt
2007-10-10 11:13           ` Michael Tokarev
2007-10-10 19:14   ` Ingo Molnar
2007-10-10 19:26     ` Michael Tokarev
2007-10-10 20:04     ` Andi Kleen
2007-10-10 23:27     ` Krzysztof Halasa

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=470F66E7.7010509@tmr.com \
    --to=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=nmiell@comcast.net \
    --cc=torvalds@linux-foundation.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.