From: Nish Aravamudan <nish.aravamudan@gmail.com>
To: Dag Nygren <dag@newtech.fi>
Cc: linux-kernel@vger.kernel.org
Subject: Re: nanosleep with small value
Date: Thu, 17 Nov 2005 09:12:58 -0800 [thread overview]
Message-ID: <29495f1d0511170912x2cceac78w766f0c800ee3f718@mail.gmail.com> (raw)
In-Reply-To: <20051117163047.30293.qmail@dag.newtech.fi>
On 11/17/05, Dag Nygren <dag@newtech.fi> wrote:
>
> Hi,
>
> seeing a strange thing happening here:
> using nanosleep() with a smallish value gives me a very long sleeptime?
>
> Is this because of a context switch being forced?
> Shouldn't the scheduler change affect that?
>
> The test program:
> ===================================
> #include <time.h>
> #include <sched.h>
> #include <stdio.h>
>
> void delay_ns(unsigned long dly)
> {
> static struct timespec time;
> int err;
> {
> time.tv_sec = 0;
> time.tv_nsec = dly;
> err = nanosleep(&time, NULL);
> if (err) {
> perror( "nanosleep failed" );
> }
> }
> }
>
>
> main()
> {
> int i;
>
> struct sched_param mysched;
> int err;
>
> if ( sched_getparam( 0, &mysched ) != 0 )
> perror( "" );
> else {
> mysched.sched_priority = sched_get_priority_max(SCHED_FIFO);
> err = sched_setscheduler(0, SCHED_FIFO, &mysched);
> if( err != 0 ) {
> fprintf (stderr,"sched_setscheduler returned: %d\n",
> err );
> perror( "" );
> }
> }
>
> for (i=0; i < 1000; i++)
> delay_ns(1000UL);
> }
> ==================================
> The result running this is:
> % time ./tst
>
> real 0m8.000s
> user 0m0.000s
> sys 0m0.000s
>
> I would have expected about 1000 * 1 us + overhead,
> but 8 seconds ????
Which kernel, what value of HZ? In either case, it's absurd to assume
that the kernel is going to provide you 1 microsecond resolution in
2.6 mainline, as the best HZ value is 1000 (1 millisecond). And we
don't busy-wait ever in nanosleep(). So the fastest your loop can run
is 1000 * 1 ms = 1 second. That's assuming the only time-consuming
thing is sleeping (minimal overhead). But, in sys_nanosleep(), we
convert nanoseconds to jiffies and add 1 if you requested any sleep
time. So,
HZ = 100
1000 * (10 + 1 ms) = 11 s
HZ = 250
1000 * (4 + 1 ms) = 5 s
HZ = 1000
1000 * (1 + 1 ms) = 2 s (which is what Dick Johnson reported).
Note, that with HZ=250, there might be some extra rounding occurring
timespec_to_jiffies() that I've forgotten.
So 8 s may not be terribly unreasonable. I don't know, though, what's
add the 3 seconds if you're using 250.
Thanks,
Nish
next prev parent reply other threads:[~2005-11-17 17:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-17 16:30 Dag Nygren
2005-11-17 16:55 ` linux-os (Dick Johnson)
2005-11-17 17:32 ` Eric Piel
2005-11-17 17:12 ` Nish Aravamudan [this message]
2005-11-17 18:47 ` Dag Nygren
[not found] <29495f1d0511171051q6088099drfe094817a01668e4@mail.gmail.com>
2005-11-17 19:11 ` Dag Nygren
2005-11-17 19:15 ` Randy.Dunlap
2005-11-17 19:17 ` Nish Aravamudan
2005-11-17 19:47 ` Frank Sorenson
2005-11-21 7:12 ` Dag Nygren
2005-11-17 20:25 Dag Nygren
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=29495f1d0511170912x2cceac78w766f0c800ee3f718@mail.gmail.com \
--to=nish.aravamudan@gmail.com \
--cc=dag@newtech.fi \
--cc=linux-kernel@vger.kernel.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®