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 13:16:48 -0700 [thread overview]
Message-ID: <20081101131648.398fe54a@infradead.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0811011541040.24707-100000@netrider.rowland.org>
On Sat, 1 Nov 2008 15:54:16 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:
> On Sat, 1 Nov 2008, Arjan van de Ven wrote:
>
> > > 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.
>
> Why is that? The fact that CPU A is busy might mean that the timer
> routines run on some other CPU... but they should still be called in
> the correct order.
Hi,
I think you misunderstand how timers work right now ;)
timers are a per cpu list, and each cpu has its own interrupt to
service this per cpu list.
now... if one cpu disables interrupts for a while, that cpus interrupts
get blocked, including that cpus timer handling irq (whichever method
is used for that)... and only that cpus timers will get delayed, the
other cpus will just keep rolling...
>
> Is it possible for timer 1 to expire before timer 2 but the handler
> gets interrupted, with the result that timer 2's handler runs to
> completion on a different CPU before timer 1's handler has managed to
> execute more than a couple of instructions? If it is then I agree,
> timer-ordering requirements between CPUs don't make much sense.
yes
>
>
> Come to think of it, is there any good reason why round_jiffies()
> doesn't always round up? It seems a lot safer.
at the time folks had concerns about making a big error in that
direction...
--
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 20:17 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
2008-11-01 19:54 ` Alan Stern
2008-11-01 20:16 ` Arjan van de Ven [this message]
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=20081101131648.398fe54a@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®