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 ????
Noticed this when trying to debug a PIC-programming
software where the delay_ns() routine is used.
Increasing the nanosleep() argument to something more than HZ
will give me the expected sleep times.
Best
--
Dag Nygren email: [email protected]
Oy Espoon NewTech Ab phone: +358 9 8024910
Träsktorpet 3 fax: +358 9 8024916
02360 ESBO Mobile: +358 400 426312
FINLAND
-
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]
