On Sun, May 28, 2000 at 09:30:00PM +1000, Andrew Morton wrote:
> Andrey Savochkin wrote:
> >
> > ...
> > However, when we finish cleanup of all timer users, I would prefer to see
> > something very simple like
> >
> > [ code..]
> >
> > del_timer() call from the handler is senseless, and such places (if any) may be
> > spotted during the audit and testing.
>
> Unfortunately, del_timer() calls within the handler are very, very
> common, for three reasons:
>
> 1: Compete bogosity :)
>
> 2: del_timer()+add_timer() -> can be replaced with mod_timer()
>
> 3: the handler is sometimes called from mainline, as well as from
> run_timer_list(). Quite valid.
>
> Number 3 is the problem.
OK, I see.
[snip]
> > >
> > > Andrey, does this need an "rmb()"?
> > ...
> > What wait_on_timers() may need is just one full memory barrier at the
> > very beginning before the loop. It may be important to put a barrier between
> > the loop and operations executed before wait_on_timers() call (for example,
> > setting do-not-readd-timer flag). However, we may have defined
> > wait_on_timers() interface so that it would be the caller's due.
>
> Uh-oh. There are three "may"s in that paragraph! Reordering of reads
:-)
wait_on_timers implementation doesn't need barriers.
It's the problem of the caller: some of them need barriers, some do not.
So, we may define the interface as we wish.
> and writes is pretty scary stuff, and it seems that kernel does it more
> often than is necessary. Fair enough - we're human. Unless it's on the
> fast path. del_timer_sync's special handling is most assuredly not on
> the fast path. Probably unnecessary but if in doubt it'll get one, OK?
No doubts here. The barrier isn't needed inside the loop.
It just prevents reordering of some operations. Certainly, the number of
identical operations isn't order dependent.
Best regards
Andrey
-
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:21 EST