Re: [PATCH RFC tip/core/rcu 13/20] rcu: increase synchronize_sched_expedited() batching

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Peter Zijlstra (peterz@infradead.org) wrote:
> On Sun, 2010-12-19 at 08:35 -0800, Paul E. McKenney wrote:
> > >  (int)((unsigned)(a) - (unsigned)(b)) < 0
> > 
> > Unfortunately, no.  :-(
> > 
> > The (int) converts from unsigned to signed, and if the upper bit of
> > the unsigned difference is non-zero, then the paragraph I quoted above
> > applies, and the standard allows the compiler to do whatever it wants.
> > 
> As noted in the previous reply, that would render quite a lot of our
> time-keeping code broken. I think its safe to assume this works.
> 
> Look at time_after() for example:
> 
> #define time_after(a,b)		\
> 	(typecheck(unsigned long, a) && \
> 	 typecheck(unsigned long, b) && \
> 	 ((long)(b) - (long)(a) < 0))

I agree with Peter: as long as the difference value is expected not to
overflow a signed long, the time_after() approach should be safe.

Now it depends if the usage Paul spotted is expected to have a
difference that overflows a signed int. It's not clear to me that it's
realistically possible from reading the patch, but I might be missing
something.

And by the way, if the difference is expected to overflow a signed int,
then we're only a factor two away from overflowing an unsigned int, so
the whole approach would be fragile.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com