Alan Cox wrote:
>
> > More hmm... synchronize_bh() doesn't do anything to stop a new BH from
> > starting as soon as it has returned. So it's safe within __global_cli()
> > and it can be used after del_timer() to give del_timer_sync() semantics,
> > but apart from that, what use is it??
>
> Im thinking
>
> del_timer();
> del_timer();
> blah
> wait_timers();
Yes, that will work in process context but can't be globally macro'ed or
inlined onto the original del_timer because extra checking is needed in
BH/IRQ context.
IMO, all ~700 uses of del_timer() should use the synchronous version
until they have been audited for del_timer_async()-safety.
> Which happens to avoid the overhead and cost in the normal timer deletion
> path.
The cost isn't too high, actually. A memory read in internal_add_timer,
a read and a write in del_timer and four writes in run_timer_list().
Much more cost if the special-case code is triggered, of course. Very
rare.
> > BTW2: is there any technical reason why the timer_struct clients haven't
> > been migrated over to use timer_list yet?
>
> Not that I know of
Tempting.
-- -akpm-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST