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] [day] [month] [year] [list]

Message-ID: <20070816212825.GL10033@linux-os.sc.intel.com>
Date:	Thu, 16 Aug 2007 14:28:25 -0700
From:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	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 Tue, Aug 14, 2007 at 05:23:00AM +0200, Nick Piggin wrote:
> On Mon, Aug 13, 2007 at 08:00:38PM -0700, Andrew Morton wrote:
> > 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.
> 
> It definitely can be. For workloads that are inherently asynchronous, high
> speed networking or disk IO (ie. with event generation significantly outside
> the control of the kernel or app), then it can be. Sure, you may just be
> switching between the main working thread and idle thread, but in that case a
> slowdown in the scheduler will be _more_ pronounced because you don't have to
> do as much work to actually switch contexts.
> 
> If there was a performance tradeoff involved, then we could think about it,
> and you might be right. But this is just a case of "write code to do direct
> calls or do indirect calls".
> 
> Ken Chen's last ia64 database benchmark I could find says schedule takes
> 6.5% of the clock cycles, the second highest consumer. Considering the
> lengths he was going to shave cycles off other paths, I'd call schedule()
> a fastpath. Would be really interesting to rerun that benchmark with CFS.
> Is anyone at Intel still doing those tests?

Yes. schedule() still is in the top 2-3 consumers of kernel time for that
workload. We did some tests when CFS was in initial days (I think V2 or so)
and it didn't show any regression.

We have plans to run that workload with 2.6.23-rc kernels, but other things
were taking priority so far...

thanks,
suresh
-
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/