On 04:41:05, 13.03.16, Juan Francisco Cantero Hurtado wrote:
> Here are the commands:
> ...
> ffmpeg
> ...
Thank you for this.
ffmpeg runs differently from gcc or make - it creates a lot of threads.
I can verify that it is indeed slower. Instead of spending 2 seconds in
'system' it takes 30 or 40 seconds on the new scheduler.
After some tests I realised that ffmpeg, when running on the present BSD
scheduler, will call sys_sched_yield() 321,068 times. When running on the
new scheduler, it will call sys_sched_yield() 2,507,894 times - nearly ten
times that. The bulk of the calls are made from this function:
lib/librthread/rthread.c:
void
_spinlock(volatile struct _spinlock *lock)
{
while (_atomic_lock(&lock->ticket))
sched_yield();
}
To verify I replaced sched_yield() with usleep():
void
_spinlock(volatile struct _spinlock *lock)
{
while (_atomic_lock(&lock->ticket))
usleep(1);
}
The number of calls to yield() dropped to 4,576.
I had a look how the Linux BFS scheduler solves this problem, and I saw
this:
/**
* yield - yield the current processor to other threads.
*
* Do not ever use this function, there's a 99% chance you're doing it wrong.
*
* The scheduler is at all times free to pick the calling task as the most
* eligible task to run, if removing the yield() call from your code breaks
* it, its already broken.
*
* Typical broken usage is:
*
* while (!event)
* yield();
*
* where one assumes that yield() will let 'the other' process run that will
* make event true. If the current task is a SCHED_FIFO task that will never
* happen. Never use yield() as a progress guarantee!!
*
* If you want to use yield() to wait for something, use wait_event().
* If you want to use yield() to be 'nice' for others, use cond_resched().
* If you still want to use yield(), do not!
*/
void __sched yield(void)
{
set_current_state(TASK_RUNNING);
sys_sched_yield();
}
EXPORT_SYMBOL(yield);
This is where I get stuck, I don't know how to replace the call to
sched_yield(), or whether it is a good idea to do so. Any advice?
--
Michal Mazurek
