From: Arjan van de Ven <arjan@infradead.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: (BUG?) round_jiffies() is non-monotonic on SMP
Date: Sat, 1 Nov 2008 09:29:05 -0700 [thread overview]
Message-ID: <20081101092905.443a2dc5@infradead.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0811011205030.21703-100000@netrider.rowland.org>
On Sat, 1 Nov 2008 12:14:41 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> 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
next prev parent reply other threads:[~2008-11-01 16:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-01 16:14 Alan Stern
2008-11-01 16:29 ` Arjan van de Ven [this message]
2008-11-01 19:54 ` Alan Stern
2008-11-01 20:16 ` Arjan van de Ven
2008-11-02 2:36 ` Alan Stern
2008-11-02 2:43 ` Arjan van de Ven
2008-11-02 15:39 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081101092905.443a2dc5@infradead.org \
--to=arjan@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=stern@rowland.harvard.edu \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®