Re: [patch] del_timer_sync scalability patch

[Andrew Morton]

Ingo Molnar <mingo@xxxxxxx> wrote:
>
> 
> * Andrew Morton <akpm@xxxxxxxx> wrote:
> 
> > Christoph Lameter <christoph@xxxxxxxxxx> wrote:
> > >
> > > When a potential periodic timer is deleted through timer_del_sync, all
> > >  cpus are scanned to determine if the timer is running on that cpu. In a
> > >  NUMA configuration doing so will cause NUMA interlink traffic which limits
> > >  the scalability of timers.
> > > 
> > >  The following patch makes the timer remember where the timer was last
> > >  started. It is then possible to only wait for the completion of the timer
> > >  on that specific cpu.
> 
> i'm not sure about this. The patch adds one more pointer to a very
> frequently used and frequently embedded data structure (struct
> timer_list), for the benefit of a rarely used API variant
> (timer_del_sync()).

True.

(We can delete timer.magic and check_timer() now.  It has served its purpose)

> Furthermore, timer->base itself is affine too, a timer always runs on
> the CPU belonging to timer->base. So a more scalable variant of
> del_timer_sync() would perhaps be possible by carefully deleting the
> timer and only going into the full loop if the timer was deleted before. 
> (and in which case semantics require us to synchronize on timer
> execution.) Or we could skip the full loop altogether and just
> synchronize with timer execution if _we_ deleted the timer. This should
> work fine as far as itimers are concerned.

If we're prepared to rule that a timer handler is not allowed to do
add_timer_on() then a recurring timer is permanently pinned to a CPU, isn't
it?

That should make things simpler?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/