On 14/03/16(Mon) 16:05, Michal Mazurek wrote:
> 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.
This is really similar to what I observed with Firefox and Chrome.
> 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?
I'd assume the problem is not in the _spinlock() implementation itself
but rather on the code calling this lock. Do you know which code is
triggering this?
See r1.13 of lib/librthread/rthread_libc.c, this is an example where a
the use of a spinlock created similar symptoms.
