From: Andi Kleen <ak@muc.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andi Kleen <ak@muc.de>,
davem@redhat.com, andrew.morton@digeo.com,
linux-kernel@vger.kernel.org
Subject: Re: [BENCHMARK] Lmbench 2.5.54-mm2 (impressive improvements)
Date: Mon, 6 Jan 2003 00:46:17 +0100 [thread overview]
Message-ID: <20030105234617.GA4714@averell> (raw)
In-Reply-To: <Pine.LNX.4.44.0301051040020.11848-100000@home.transmeta.com>
On Sun, Jan 05, 2003 at 07:51:44PM +0100, Linus Torvalds wrote:
>
> On 5 Jan 2003, Andi Kleen wrote:
> >
> > Regarding the EFLAGS handling: why can't you just do
> > a pushfl in the vsyscall page before pushing the 6th arg on the stack
> > and a popfl afterwards.
>
> I did that originally, but timings from Jamie convinced me that it's
> actually a quite noticeable overhead for the system call path.
>
> You should realize that the 5-9% slowdown in schedule (which I don't like)
> comes with a 360% speedup on a P4 in simple system call handling (which I
> _do_ like). My P4 does a system call in 428 cycles as opposed to 1568
> cycles according to my benchmarks.
According to my benchmarks the slowdown on context switch is a lot
more than 5-9% on P4:
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
with wrmsr Linux 2.5.54 2.410 3.5600 6.0300 3.9900 34.8 8.59000 43.7
no wrmsr Linux 2.5.54 1.270 2.3300 4.7700 2.5100 29.5 4.16000 39.2
That looks more like between 10%-51%
[Note I don't trust the numbers completely, the slowdown looks a bit too
extreme especially for the 16p case. But it is clear that it is a lot
slower]
I haven't benchmarked pushfl/popfl, but I cannot imagine it being that
slow to offset that. I agree that syscalls are a slightly hotter path than the
context switch, but hurting one for the other that much looks a bit
misbalanced.
>
> And part of the reason for the huge speedup is that the vsyscall/sysenter
> path is actually pretty much the fastest possible. Yes, it would have been
I can think of some things to speed it up more. e.g. replace all the
push / pop in SAVE/RESTORE_ALL with sub $frame,%esp ; movl %reg,offset(%esp)
and movl offset(%esp),%reg ; addl $frame,%esp. This way the CPU has
no dependencies between all the load/store options unlike push/pop.
(that is what all the code optimization guides recommend and gcc / icc
do too for saving/restoring of lots of registers)
Perhaps that would offset a pushfl / popfl in kernel mode, may be worth
a try.
-Andi
P.S.: For me it is actually good if the i386 context switch is slow.
On x86-64 I have some ugly wrmsrs in the context switch for the
64bit segment base rewriting too and slowing down i386 like this will
make the 64bit kernel look better compared to 32bit ;););)
next prev parent reply other threads:[~2003-01-05 23:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <94F20261551DC141B6B559DC4910867204491F@blr-m3-msg.wipro.com.suse.lists.linux.kernel>
[not found] ` <3E155903.F8C22286@digeo.com.suse.lists.linux.kernel>
2003-01-03 18:40 ` [BENCHMARK] Lmbench 2.5.54-mm2 (impressive improvements) Andi Kleen
2003-01-03 21:32 ` Andrew Morton
2003-01-05 1:01 ` Andrew Morton
2003-01-05 3:35 ` Linus Torvalds
2003-01-05 3:51 ` Linus Torvalds
2003-01-05 3:54 ` Andrew Morton
2003-01-05 3:52 ` Linus Torvalds
2003-01-05 10:06 ` Andi Kleen
2003-01-05 18:51 ` Linus Torvalds
2003-01-05 23:46 ` Andi Kleen [this message]
2003-01-06 1:33 ` Linus Torvalds
2003-01-06 2:05 ` Andi Kleen
2003-01-06 0:58 ` H. Peter Anvin
2003-01-05 9:18 ` Andrew Morton
2003-01-03 8:59 Aniruddha M Marathe
2003-01-03 9:33 ` Andrew Morton
2003-01-03 10:24 ` David S. Miller
2003-01-03 10:22 ` Andrew Morton
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=20030105234617.GA4714@averell \
--to=ak@muc.de \
--cc=andrew.morton@digeo.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox