From: george anzinger <george@mvista.com>
To: Paul Larson <plars@linuxtestproject.org>
Cc: Andrew Morton <akpm@osdl.org>,
johnstul@us.ibm.com, Ulrich Drepper <drepper@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: ltp nanosleep02 test
Date: Tue, 05 Aug 2003 12:06:44 -0700 [thread overview]
Message-ID: <3F300044.9000306@mvista.com> (raw)
In-Reply-To: <1060095904.28044.105.camel@plars>
Paul Larson wrote:
> On Mon, 2003-08-04 at 18:22, Andrew Morton wrote:
>
>>OK, thanks.
>>
>>Paul, if nanosleep2 is really dead then you should bury it and stop
>>scaring people ;)
>
> Actually this test will pass just fine if you increase USEC_PRECISION to
> something more reasonable than 100. However it looks like whoever wrote
> this test made it intentionally low. This is the comment right before
> the #define USEC_PRECISION 100:
> /*
> * Define here the "rem" precision in microseconds,
> * Various implementations will provide different
> * precisions. The -aa tree provides up to usec precision.
> * NOTE: all the trees that don't provide a precision of
> * the order of the microseconds are subject to an userspace
> * live lock condition with glibc under a flood of signals,
> * the "rem" field would never change without the increased
> * usec precision in the -aa tree.
> */
> So does anyone know if this patch from the -aa tree is reasonable or has
> a chance of making it into the mainline kernel? Does this livelock
> situation still exist or was it solved by other means? If this is no
> longer a potential problem then I will gladly remove the test.
I haven't seen the patch :( There is a little misdirection in that
comment, however. The kernel rounds up the time to the nearest
resolution and then adds that resolution (resolution is 1/HZ, by the
way). The round up is required by the standard as is the add. The
add is to make sure the expiry time is AFTER and never before the
requested time.
What is passed back as the remaining time is the true remaining time
after this calculation.
The live lock would occur if the caller then used that time to sleep
again (i.e. to complete the sleep) as the kernel would again add the
1/HZ to the given value. So each signal, the time would be extended
by a jiffie.
The best way to solve this is to use the absolute time version of
clock_nanosleep, but, sigh, that means a change in glibc.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
parent reply other threads:[~2003-08-05 19:07 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <1060095904.28044.105.camel@plars>]
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=3F300044.9000306@mvista.com \
--to=george@mvista.com \
--cc=akpm@osdl.org \
--cc=drepper@redhat.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=plars@linuxtestproject.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;
as well as URLs for NNTP newsgroup(s).