linux-kernel - Re: hackbench [pthread mode] regression with 2.6.29-rc3

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]

Date:	Mon, 02 Feb 2009 09:12:14 +0800
From:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Lin Ming <ming.m.lin@...el.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: hackbench [pthread mode] regression with 2.6.29-rc3

On Sun, 2009-02-01 at 10:57 +0100, Peter Zijlstra wrote:
> On Sun, 2009-02-01 at 10:17 +0100, Peter Zijlstra wrote:
> > On Sun, 2009-02-01 at 16:29 +0800, Lin Ming wrote:
> > > > Bisect located below patch.
> > > > commit 490dea45d00f01847ebebd007685d564aaf2cd98
> > > > Author: Peter Zijlstra <peterz@...radead.org>
> > > > Date:   Mon Nov 24 17:06:57 2008 +0100
> > > > 
> > > >    itimers: remove the per-cpu-ish-ness
> > > > 
> > > >    Either we bounce once cacheline per cpu per tick, yielding n^2 bounces
> > > >    or we just bounce a single..
> > > > 
> > > >    Also, using per-cpu allocations for the thread-groups complicates the
> > > >    per-cpu allocator in that its currently aimed to be a fixed sized
> > > >    allocator and the only possible extention to that would be vmap based,
> > > >    which is seriously constrained on 32 bit archs.
> > > > 
> > > > 
> > > > After above patch is reverted, hackbench result is restored.
> > > 
> > > oltp has ~3% regression with 2.6.29-rc3 on 4core*2p stokley machine.
> > > After above patch reverted, the regression disappeared.
> > 
> > *sigh*, did they gain anything with introduction of the per-cpu crap?
> 
> No it wouldn't have, I just missed something obvious,.. :-(
> 
> I wish we never merged that crap...
process timer (by setitimer) isn't good. Is per-cpu itimer to improve it?

Prior to kernel 2.6.28, process timer implementation is poor. When the process timer
is near to expire, threads will sum the time from all threads of the thread group
over and over again. If there are thousands of threads, kernel might hang eventually.
I ran into it a couple of months ago when I tried to enable specweb2005 (Apache+PHP
thread mode).

So the per-cpu itimer could improve this situation when thread number is far bigger than
cpu number. I didn't retry specweb2005 with 2.6.28.

-yanmin


--
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/