Re: nanosleep with small value

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/17/05, Dag Nygren <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux