Re: [RFC][PATCH] TIMER_BH-less smptimers

[Dipankar Sarma <dipankar@in.ibm.com>]

On Mon, May 20, 2002 at 11:31:05PM +1000, Anton Blanchard wrote:
> :) I was surprised it worked with the missing spin_unlock too. Im
> testing the fixed diff now, so far it looks good.

I was positively invaded by space aliens while writing that code.


> > I am curious about performance of smptimers. It seems that
> > webserver benchmark performance worsens with smptimers (Ingo version)
> > contrary to our expectations. Do you see this ? If so, could this
> > happen because -
> > 
> > 1) Bouncing around of global_bh_lock cacheline by more cpus compared
> > to earlier timer implemenation ?
> > 2) All per-cpu timers invoked from timer_bh running in one cpu ?
> > 
> > Do you see any other side-effects of smptimers ?
> 
> We used to see bad behaviour. It turned out to be the per cpu
> timer interrupt firing at exactly the same time on all cpus. One
> cpu would successfully spin_trylock and the others would fail
> and postpone the work.

This makes me wonder if using a per-cpu tasklet in my patch
is a bad idea after all. Perhaps Ingo had figured it out already
and used a single acquisition of global_bh_lock to fire
timers for all CPUs when timers get deferred from the local
timer interrupt.

In an ideal world where there are no BHs, we can parallelize
the timers like I did. But with global_bh_lock serialization,
I am not sure anymore if that is a good idea. I will try to
get some benchmark measurements done with these two approaches.

> 
> We now evenly space the per cpu interrupts. Does intel do the same?

AFAICS, no. But then I am still learning.

Thanks
-- 
Dipankar Sarma  <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.