[FFmpeg-devel] [PATCH] Yield on AVERROR(EAGAIN).

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Fri, Mar 05, 2010 at 02:58:57AM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Fri, Mar 05, 2010 at 02:22:18AM +0000, M?ns Rullg?rd wrote:
>> >> Ramiro Polla <ramiro.polla at gmail.com> writes:
>> >> 
>> >> > Hi,
>> >> >
>> >> > Currently FFmpeg eats 100% cpu on devices that return EAGAIN. Attached
>> >> > patch makes FFmpeg yield when it gets EAGAIN. In Windows it gets down
>> >> > to normal cpu levels, but on Linux this didn't work as I expected, it
>> >> > still eats 100% cpu. Any ideas?
>> >> 
>> >> It's the wrong approach.  The spec for sched_yield says:
>> >> 
>> >>   The sched_yield() function shall force the running thread to
>> >>   relinquish the processor until it again becomes the head of its
>> >>   thread list.
>> >> 
>> >> On some kernels this puts the thread out of action for a full tick,
>> >> which is probably what you are seeing on Windows (yes, it has a
>> >> different name there).  On a modern Linux system it will merely invoke
>> >> the scheduler, which will notice that nothing else wants to run and
>> >> put this thread back on the CPU immediately.  Check with "vmstat 1" if
>> >> system the call rate shoots up while running this.
>> >> 
>> >> The correct solution is to make the devices somehow notify when input
>> >> is available so the process can sleep properly while waiting.  On Unix
>> >> systems this is typically done with select() on a file descriptor.  On
>> >> Windows something like WaitForMultiPleObJectS() is used.  Perhaps that
>> >> is something we could create an abstraction for.
>> >
>> > The question is not only what is the philosophically correct approach but
>> > also how complex and portable it is.
>> > And yield() is quite portable and as you see from this patch quite simple.
>> 
>> Simple is irrelevant when it fails to solve the problem.
>
> but it should solve the problem

No, it doesn't.

> the cputime is made available to other processes. If its 100% when there
> are no other processes is irrelevant.

Wrong.  It still increases power consumption, which can be very
relevant.

> Also usleep() could be tried when sched_yield() doesnt do what we want it
> to.

I repeat, sched_yield() doesn't do the right thing.

> Again to clarify my point, i understand and agree that select() is
> the proper way but i fear it wont ever be implemented or if it is
> will be a quite complex mess. a simple
> usleep/nanosleep/sched_yield/whatever is quite appealing to me due
> to its simplicity and i dont see any real world advantage for us in
> select anyway but then i did not compare them in actual
> implementation ...

A short sleep would be much preferable over a pointless kernel
roundtrip.  The problem is how to avoid sleeping too much.

> and id gladly be proofen wrong with a simple select() based [PATCH]

Which devices are we talking about here?

-- 
M?ns Rullg?rd
mans at mansr.com