LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
paulmck@linux.vnet.ibm.com, Nadia Derbey <Nadia.Derbey@bull.net>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: Scalability requirements for sysv ipc
Date: Tue, 25 Mar 2008 16:50:06 +0100 [thread overview]
Message-ID: <1206460206.4414.21.camel@marge.simson.net> (raw)
In-Reply-To: <47E55945.10109@colorfullife.com>
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
On Sat, 2008-03-22 at 20:08 +0100, Manfred Spraul wrote:
> just the normal performance of 2.6.25-rc3 is abyssimal, 55 to 60% slower
> than 2.6.18.8:
After manually reverting 3e148c79938aa39035669c1cfa3ff60722134535,
2.6.25.git scaled linearly, but as you noted, markedly down from earlier
kernels with this benchmark. 2.6.24.4 with same revert, but all
2.6.25.git ipc changes piled on top still performed close to 2.6.22, so
I went looking. Bisection led me to..
8f4d37ec073c17e2d4aa8851df5837d798606d6f is first bad commit
commit 8f4d37ec073c17e2d4aa8851df5837d798606d6f
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Fri Jan 25 21:08:29 2008 +0100
sched: high-res preemption tick
Use HR-timers (when available) to deliver an accurate preemption tick.
The regular scheduler tick that runs at 1/HZ can be too coarse when nice
level are used. The fairness system will still keep the cpu utilisation 'fair'
by then delaying the task that got an excessive amount of CPU time but try to
minimize this by delivering preemption points spot-on.
The average frequency of this extra interrupt is sched_latency / nr_latency.
Which need not be higher than 1/HZ, its just that the distribution within the
sched_latency period is important.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
:040000 040000 ab225228500f7a19d5ad20ca12ca3fc8ff5f5ad1 f1742e1d225a72aecea9d6961ed989b5943d31d8 M arch
:040000 040000 25d85e4ef7a71b0cc76801a2526ebeb4dce180fe ae61510186b4fad708ef0211ac169decba16d4e5 M include
:040000 040000 9247cec7dd506c648ac027c17e5a07145aa41b26 950832cc1dc4d30923f593ecec883a06b45d62e9 M kernel
..and I verified it via :-/ echo 7 > sched_features in latest. That
only bought me roughly half though, so there's a part three in there
somewhere.
-Mike
[-- Attachment #2: xxxx.pdf --]
[-- Type: application/pdf, Size: 17909 bytes --]
next prev parent reply other threads:[~2008-03-25 15:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-21 9:41 Scalability requirements for sysv ipc (was: ipc: store ipcs into IDRs) Manfred Spraul
2008-03-21 12:45 ` Nadia Derbey
2008-03-21 13:33 ` Scalability requirements for sysv ipc Manfred Spraul
2008-03-21 14:13 ` Paul E. McKenney
2008-03-21 16:08 ` Manfred Spraul
2008-03-22 5:43 ` Mike Galbraith
2008-03-22 10:10 ` Manfred Spraul
2008-03-22 11:53 ` Mike Galbraith
2008-03-22 14:22 ` Manfred Spraul
2008-03-22 19:08 ` Manfred Spraul
2008-03-25 15:50 ` Mike Galbraith [this message]
2008-03-25 16:13 ` Peter Zijlstra
2008-03-25 18:31 ` Mike Galbraith
2008-03-26 6:18 ` Mike Galbraith
2008-03-30 14:12 ` Scalability requirements for sysv ipc (+namespaces broken with SEM_UNDO) Manfred Spraul
2008-03-30 15:21 ` David Newall
2008-03-30 17:18 ` Mike Galbraith
2008-04-04 14:59 ` Nadia Derbey
2008-04-04 15:03 ` Nadia Derbey
2008-03-22 19:35 ` Scalability requirements for sysv ipc Mike Galbraith
2008-03-23 6:38 ` Manfred Spraul
2008-03-23 7:15 ` Mike Galbraith
2008-03-23 7:08 ` Mike Galbraith
2008-03-23 7:20 ` Mike Galbraith
2008-03-27 22:29 ` Bill Davidsen
2008-03-28 9:49 ` Manfred Spraul
2008-03-25 16:00 ` Nadia Derbey
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=1206460206.4414.21.camel@marge.simson.net \
--to=efault@gmx.de \
--cc=Nadia.Derbey@bull.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--subject='Re: Scalability requirements for sysv ipc' \
/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
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).