From: linux@horizon.com
To: linux-kernel@vger.kernel.org, npiggin@suse.de
Cc: linux@horizon.com
Subject: Re: [patch] change futex_wait() to hrtimers
Date: 14 Mar 2007 20:03:10 -0400 [thread overview]
Message-ID: <20070315000310.15266.qmail@science.horizon.com> (raw)
> BTW. my futex man page says timeout's contents "describe the maximum duration
> of the wait". Surely that should be *minimum*? Michael cc'ed.
Er, the intent of the wording is to say "futex will wait until uaddr
no longer contains val, or the timeout expires, whichever happens first".
One option for selecting different clock resolutions is to use the
clockid_t from the POSIX clock_gettime() family. That is, specify the
clock that a wait uses, and then have a separate mechanism for turning
a resolution requirement into a clockid_t.
(And there can be default clocks for interfaces that don't specify one
explicitly.)
Although clockid_t is pretty generic, it's biased toward an enumerated
list of clocks rather than a continuous resolution. Fortunately,
that seems to match the implementation ideas. The question is how
much the timeout gets rounded, and the choices are currently jiffies
or microseconds.
A related option may be whether rounding down is acceptable. For some
applications (periodic polling for events), it's fine. For others,
it's not. Thus, while it's okay to specify such clocks explicitly,
it'd probably be a good idea to forbid selecting them as the default
for interfaces that don't specify a clock explicitly.
I had some code that suffered 1 ms buzz-loops on Solaris because poll(2)
would round the timeout interval down, but the loop calling it would
explicitly check whether the timeout had expired using gettimeofday()
and would keep re-invoking poll(pollfds, npollfds, 1) until the timeout
really did expire.
next reply other threads:[~2007-03-15 0:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-15 0:03 linux [this message]
[not found] <200703110814.l2B8EaI1007615@shell0.pdx.osdl.net>
[not found] ` <20070312011259.3834A1801C4@magilla.sf.frob.com>
2007-03-12 9:10 ` Ingo Molnar
2007-03-12 9:16 ` Nick Piggin
2007-03-12 11:02 ` Ingo Molnar
2007-03-12 11:13 ` Nick Piggin
2007-03-12 11:19 ` Ingo Molnar
2007-03-12 11:29 ` Nick Piggin
2007-03-12 11:38 ` Ingo Molnar
2007-03-12 11:52 ` Nick Piggin
2007-03-12 12:21 ` Ingo Molnar
2007-03-12 12:36 ` Nick Piggin
2007-03-12 11:19 ` Thomas Gleixner
2007-03-12 11:27 ` Andi Kleen
2007-03-12 11:00 ` Thomas Gleixner
2007-03-12 10:58 ` Andi Kleen
2007-03-12 11:04 ` Ingo Molnar
2007-03-12 11:20 ` Andi Kleen
2007-03-12 11:28 ` Ingo Molnar
2007-03-12 14:12 ` Theodore Tso
2007-03-12 14:22 ` Andi Kleen
2007-03-12 14:31 ` Ingo Molnar
2007-03-12 14:32 ` Nick Piggin
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=20070315000310.15266.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/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®