Re: (BUG?) round_jiffies() is non-monotonic on SMP

From: Arjan van de Ven
Date: Sat Nov 01 2008 - 12:28:59 EST


On Sat, 1 Nov 2008 12:14:41 -0400 (EDT)
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:

> Is it generally recognized that round_jiffies() can be non-monotonic
> on SMP systems? By this, I mean that if cpu-a and cpu-b respectively
> do:
>
> ra = round_jiffies(ja);
>
> and
>
> rb = round_jiffies(jb);
>
> then the ordering of ra and rb can be opposite the ordering of ja and
> jb.

round_jiffies() tends to be used (and is designed to be used) for cases
where you don't really care when exactly timers will fire... including
the order against other such timers.


> If this is known, is it regarded as a potential problem? It certainly
> seems likely that some code somewhere depends on timeouts expiring in
> the correct order.

I don't think timeouts EVER have that guarantee between different cpus;
even if you don't round the timeouts.
After all, your CPU A can be in some delay loop with irqs off for
longer than the delta was, and boom.. the timers fire in different
order.
If we ever have such ordering requirements in the kernel that
don't handle this... they're a bug...

>
> Alan Stern
>
> P.S.: As a related matter, it seems very odd that we don't have a
> round_jiffies_up() routine. Surely there are plenty of places where
> it doesn't matter if an event is a little late but where the event
> must not be early. (I know two such places offhand.) Any objection
> to having one added?

no objection per se, but I would almost argue we should convert such
places to range timers....
that way the kernel can, rather an aligning them, group them with other
activity.


--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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/