linux-kernel - Re: lmbench ctxsw regression with CFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070813200038.7fc8a9e6.akpm@linux-foundation.org>
Date:	Mon, 13 Aug 2007 20:00:38 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Nick Piggin <npiggin@...e.de>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: lmbench ctxsw regression with CFS

On Mon, 13 Aug 2007 14:30:31 +0200 Jens Axboe <jens.axboe@...cle.com> wrote:

> On Mon, Aug 06 2007, Nick Piggin wrote:
> > > > What CPU did you get these numbers on? Do the indirect calls hurt much 
> > > > on those without an indirect predictor? (I'll try running some tests).
> > > 
> > > it was on an older Athlon64 X2. I never saw indirect calls really 
> > > hurting on modern x86 CPUs - dont both CPU makers optimize them pretty 
> > > efficiently? (as long as the target function is always the same - which 
> > > it is here.)
> > 
> > I think a lot of CPUs do. I think ia64 does not. It predicts
> > based on the contents of a branch target register which has to
> > be loaded I presume before instructoin fetch reaches the branch.
> > I don't know if this would hurt or not.
> 
> Testing on ia64 showed that the indirect calls in the io scheduler hurt
> quite a bit, so I'd be surprised if the impact here wasn't an issue
> there.

With what workload?  lmbench ctxsw?  Who cares?

Look, if you're doing 100,000 context switches per second per then *that*
is your problem.  You suck, and making context switches a bit faster
doesn't stop you from sucking.  And ten microseconds is a very long time
indeed.

Put it this way: if a 50% slowdown in context switch times yields a 5%
improvement in, say, balancing decisions then it's probably a net win.

Guys, repeat after me: "context switch is not a fast path".  Take that
benchmark and set fire to it.

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