Hi !
I would like to implement a system to actively wait something but
without eating a lot of CPU.
Thus, I would like to know if there is any way to force the scheduler of
Linux to pre-empt the current process/thread, like the "sginap(0)"
function within IRIX.
Moreover, I don't want to have to be root to execute such function.
Friendly
Damien TOURAINE
On Tue, 24 Jul 2001, Damien TOURAINE wrote:
> Hi !
> I would like to implement a system to actively wait something but
> without eating a lot of CPU.
> Thus, I would like to know if there is any way to force the scheduler of
> Linux to pre-empt the current process/thread, like the "sginap(0)"
> function within IRIX.
> Moreover, I don't want to have to be root to execute such function.
>
> Friendly
> Damien TOURAINE
>
Try sched_yield(). Accounting may still be messed up so the process
may be 'charged' for CPU time that it gave up. Also, usleep(n) works
very well with accounting working.
This works, does not seem to load the system, but `top` shows
99+ CPU time usage:
main()
{
for(;;) sched_yield();
}
This works and `top` shows nothing being used:
main()
{
for(;;) usleep(1);
}
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
On Tuesday 24 July 2001 13:54, Richard B. Johnson wrote:
> Try sched_yield(). Accounting may still be messed up so the process
> may be 'charged' for CPU time that it gave up. Also, usleep(n) works
> very well with accounting working.
>
> This works, does not seem to load the system, but `top` shows
> 99+ CPU time usage:
>
> main()
> {
> for(;;) sched_yield();
>
> }
This may not be an accounting problem. If the system has nothing else to do,
it'll just re-schedule your yielding thread.
How much of that 99% cpu usage is user and how much of it is system?
Basically what the above does is beat the scheduler to death...
> This works and `top` shows nothing being used:
>
> main()
> {
>
> for(;;) usleep(1);
>
> }
And here you DO block for a bit without getting called back immediately.
I don't think that's an accounting thing, I think it's different behavior.
(Could be wrong, as always...)
>
> Cheers,
> Dick Johnson
Rob
Rob Landley wrote:
>On Tuesday 24 July 2001 13:54, Richard B. Johnson wrote:
>
>>Try sched_yield(). Accounting may still be messed up so the process
>>may be 'charged' for CPU time that it gave up. Also, usleep(n) works
>>very well with accounting working.
>>
>>This works, does not seem to load the system, but `top` shows
>>99+ CPU time usage:
>>
>>main()
>>{
>> for(;;) sched_yield();
>>
>>}
>>
>This may not be an accounting problem. If the system has nothing else to do,
>it'll just re-schedule your yielding thread.
>
>How much of that 99% cpu usage is user and how much of it is system?
>Basically what the above does is beat the scheduler to death...
>
In my case, as the process/thread that call the "sched_yield();"
function "actively" waits for another process/thread finish its job, the
process won't be the only one in the queue of activ job ...
Then, it won't use 99% of the time ...
>>This works and `top` shows nothing being used:
>>
>>main()
>>{
>>
>> for(;;) usleep(1);
>>
>>}
>>
>And here you DO block for a bit without getting called back immediately.
>
However, I would like to know the scheduler frequency to switch between
tasks.
If it's above 1 us, the usleep don't match my requirements ...
However, thanks for your quick and pertinent answer !
Friendly
Damien TOURAINE