Re: Possible spin-problem in nanosleep()

Re: Possible spin-problem in nanosleep()

[Robert Hancock]

Richard B. Johnson wrote:
> Is this a known problem? Is it going to be fixed? In a possibly
> related note, the following:
> 
> main()
> {
>     for(;;)
>         sched_yield();
> }
> 
> .... is shown to be spinning, by 'top' not sleeping. This, even though
> it is giving up its quantum continuously.

If no other processes are runnable, this will still use 100% of the CPU.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Possible spin-problem in nanosleep()

[Richard B. Johnson]

The man pages say usleep() is obsolete and one should
use nanosleep().

nanosleep() appears to have a problem. It may be just an
'accounting' problem, but it isn't pretty. Code that used
to use usleep() to spend most of it's time sleeping, used
little or no CPU time as shown by `top`. The same code,
converted to nanosleep() appears to spend a lot of CPU
cycles spinning. The result is that `top` or similar
programs show lots of wasted CPU time.

In the following 'daemon' was converted to nanosleep(). It
sleeps for 100 milliseconds. Process 'xray' was not converted
and it sleeps for 100 milliseconds also. They used to both
accumulate roughly the same amount of time. They simply sleep,
wake up to sample some status, then go back to sleep. This
is an embedded system that was running for about 10 hours.

PID   NAME            STA CPU     MEM   EXE   Command line
1     (init)          S   0.00    368   8     /sbin/init auto 
2     (keventd)       S   0.00    368   8 
3     (ksoftirqd_CPU0)S   0.00    368   8 
4     (kswapd)        S   0.00    368   8 
5     (bdflush)       S   0.00    368   8 
6     (kupdated)      S   0.00    368   8 
10    (syslog)        S   0.00    268   4     /sbin/syslog 
12    (daemon)        S   5.93    260   4     /sbin/daemon 
14    (xray)          S   0.71    264   8     /bin/xray control


Is this a known problem? Is it going to be fixed? In a possibly
related note, the following:

main()
{
     for(;;)
         sched_yield();
}

.... is shown to be spinning, by 'top' not sleeping. This, even though
it is giving up its quantum continuously.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: Possible spin-problem in nanosleep()

[Andreas Schwab]

"Richard B. Johnson" <linux-os@analogic.com> writes:

> nanosleep() appears to have a problem. It may be just an
> 'accounting' problem, but it isn't pretty. Code that used
> to use usleep() to spend most of it's time sleeping, used
> little or no CPU time as shown by `top`. The same code,
> converted to nanosleep() appears to spend a lot of CPU
> cycles spinning. The result is that `top` or similar
> programs show lots of wasted CPU time.

usleep() is just a wrapper around nanosleep().  Are you sure you got the
units right?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Possible spin-problem in nanosleep()

[Richard B. Johnson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1257 bytes --]

On Thu, 23 Jun 2005, Andreas Schwab wrote:

> "Richard B. Johnson" <linux-os@analogic.com> writes:
>
>> nanosleep() appears to have a problem. It may be just an
>> 'accounting' problem, but it isn't pretty. Code that used
>> to use usleep() to spend most of it's time sleeping, used
>> little or no CPU time as shown by `top`. The same code,
>> converted to nanosleep() appears to spend a lot of CPU
>> cycles spinning. The result is that `top` or similar
>> programs show lots of wasted CPU time.
>
> usleep() is just a wrapper around nanosleep().  Are you sure you got the
> units right?
>
> Andreas.
>

Yeah nano is -9 micro is -6, three more zeros when using nano.
I note that the actual syscall is __NR_nanosleep = 162. I don't
understand the discrepancy either.

> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: Possible spin-problem in nanosleep()

[Richard B. Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed, Size: 3194 bytes --]

Andreas,

Additional input: It seems that it's not the usleep(), but
some kind of scheduling phenomena makes the difference.
The following code will show different amounts of CPU time
after a few hours of running on an otherwise unused
system (not even a network card), a real "quiet" system.

The first task forked() seems to get about 5 times the CPU
time of the second. Since the first task used nanosecond()
it was blamed on nanosecond(), but instead it seems to have
something to do with the order in which children are created.


#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>

int main(int argx, char *argv[])
{
     volatile int i;
     struct timespec ts;
     switch(fork())
     {
     case 0:	// Child
         strcpy(argv[0], "Using nanosleep()");
         for(;;)
         {
             ts.tv_sec = 0;
             ts.tv_nsec = 1000000;		// 1 milisecond
             (void)nanosleep(&ts, NULL);
             for(i=0; i< 0x00010000; i++)	// Do work
                 ;
         }
         break;
     case -1:	// Failure
         abort();
         break;
     default:
         break;
     }
     switch(fork())
     {
     case 0:	// Child
         strcpy(argv[0], "Using usleep()");
         for(;;)
         {
             (void)usleep(1000);			// 1 millisecond
             for(i=0; i< 0x00010000; i++)	// Do work
                 ;
         }
         break;
     case -1:	// Failure
         abort();
         break;
     default:
         break;
     }
     pause();
     return 0;
}


On Thu, 23 Jun 2005, Richard B. Johnson wrote:

> On Thu, 23 Jun 2005, Andreas Schwab wrote:
>
>> "Richard B. Johnson" <linux-os@analogic.com> writes:
>> 
>>> nanosleep() appears to have a problem. It may be just an
>>> 'accounting' problem, but it isn't pretty. Code that used
>>> to use usleep() to spend most of it's time sleeping, used
>>> little or no CPU time as shown by `top`. The same code,
>>> converted to nanosleep() appears to spend a lot of CPU
>>> cycles spinning. The result is that `top` or similar
>>> programs show lots of wasted CPU time.
>> 
>> usleep() is just a wrapper around nanosleep().  Are you sure you got the
>> units right?
>> 
>> Andreas.
>> 
>
> Yeah nano is -9 micro is -6, three more zeros when using nano.
> I note that the actual syscall is __NR_nanosleep = 162. I don't
> understand the discrepancy either.
>
>> -- 
>> Andreas Schwab, SuSE Labs, schwab@suse.de
>> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
>> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
>> "And now for something completely different."
>> 
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
> Notice : All mail here is now cached for review by Dictator Bush.
>                 98.36% of all statistics are fiction.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: Possible spin-problem in nanosleep()

[Alan Cox]

For most platforms the scheduler measured busy/idle time is from the
timer tick. That means its sampled so you are limited to accurate
information on sleep/wake changes occuring at 1/2 the clock rate or
less.

Alan

Re: Possible spin-problem in nanosleep()

[Richard B. Johnson]

On Thu, 23 Jun 2005, Alan Cox wrote:

> For most platforms the scheduler measured busy/idle time is from the
> timer tick. That means its sampled so you are limited to accurate
> information on sleep/wake changes occuring at 1/2 the clock rate or
> less.
>
> Alan
>

So, with a 100 ms sleep, I should see 100 +/- 1 ms, possibly 2 ms
difference in sleep between processes. Then they might not get the
CPU for a whole quantum? Wouldn't each task get the CPU for a whole
tick?

Are you saying that each might get the CPU from between 0 and 1
tick, i.e., asynchronous with the tick? If so, depending upon the
phase between the timer-tick and when a task gets awakened, a task
may never get any CPU time at all. If so, this is a bug.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: Possible spin-problem in nanosleep()

[Alan Cox]

On Gwe, 2005-06-24 at 12:42, Richard B. Johnson wrote:
> Are you saying that each might get the CPU from between 0 and 1
> tick, i.e., asynchronous with the tick? If so, depending upon the
> phase between the timer-tick and when a task gets awakened, a task
> may never get any CPU time at all. If so, this is a bug.

No I'm saying the samping rate of the timer tick limits the resolution
of accounting of data (ie straight information theory limits)

Re: Possible spin-problem in nanosleep()

[Mike Galbraith]

At 06:18 PM 6/26/2005 +0100, Alan Cox wrote:
>On Gwe, 2005-06-24 at 12:42, Richard B. Johnson wrote:
> > Are you saying that each might get the CPU from between 0 and 1
> > tick, i.e., asynchronous with the tick? If so, depending upon the
> > phase between the timer-tick and when a task gets awakened, a task
> > may never get any CPU time at all. If so, this is a bug.
>
>No I'm saying the samping rate of the timer tick limits the resolution
>of accounting of data (ie straight information theory limits)

(precisely stated [again])