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

["Zhang, Yanmin" <yanmin_zhang@linux.intel.com>]

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@infradead.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