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: <20070806032949.GA16401@wotan.suse.de>
Date:	Mon, 6 Aug 2007 05:29:49 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: lmbench ctxsw regression with CFS

On Sat, Aug 04, 2007 at 08:50:37AM +0200, Ingo Molnar wrote:
> 
> * Nick Piggin <npiggin@...e.de> wrote:
> 
> > Oh good. Thanks for getting to the bottom of it. We have normally 
> > disliked too much runtime tunables in the scheduler, so I assume these 
> > are mostly going away or under a CONFIG option for 2.6.23? Or...?
> 
> yeah, they are all already under CONFIG_SCHED_DEBUG. (it's just that the 
> add-on optimization is not upstream yet - the tunings are still being 

Ah, OK. So long as that goes upstream I'm happy... and it is good
to see that with that patch, the base context switching performance
_has_ actually gone up like I had hoped. Nice.


> tested) Btw., with SCHED_DEBUG we now also have your domain-tree sysctl 
> patch upstream, which has been in -mm for a near eternity.
> 
> > 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.


> > I must say that I don't really like the indirect calls a great deal, 
> > and they could be eliminated just with a couple of branches and direct 
> > calls.
> 
> yeah - i'll try that too. We can make the indirect call the uncommon 
> case and a NULL pointer be the common case, combined with a 'default', 
> direct function call. But i doubt it makes a big (or even measurable) 
> difference.

You might be right there.
-
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/