Very high CPU usage running growisofs
dillon at apollo.backplane.com
Mon Sep 18 10:43:45 PDT 2006
:On Mon, Sep 18, 2006 at 04:37:37PM +0100, Steve O'Hara-Smith wrote:
:> I finally got fed up enough with this to try things I don't really
:> understand. I found that adding a usleep(10000); before the only call to
:> __thread_yield() - which just calls sched_yield() restored the performance
:> of growisofs to normal (and yes the DVDs burnt with it still work fine). In
:> more detail I turned this loop:
:I'm fully aware of it, but the issue is that it changes the original
:intention of the code a lot. I never got around to implement an adaptive
:> Can anyone comment on the sanity or otherwise of this change ?
:> Presumably this form of loop - similar to those mentioned in the
:> "Threadding issue" thread in July - does not cause similar problems in
:> FreeBSD or Linux does anyone understand what the difference is in DragonFly
:> that causes it to cause problems here.
:The userland scheduler of pthread sees that it has no other runnable
:thread and continues the execution. FreeBSD or Linux go to the kernel
:and the kernel scheduler most likely decides to switch to a different
:process. But in principle, it should show the same behaviour.
Well, from my point of view, the code is simply broken. The code
is making two false assumptions. First, it is assuming that the ONLY
other process running is another thread that will immediately update
the condition of the loop when allowed to run. What if there are other
processes in the system that the kernel decides to schedule instead?
Nowhere was the yield code ever intended to allow every single other
runnable thread in the system run before returning control to the caller.
Secondly, it assumes that the yield will always transfer control to
this other process. What am I supposed to do? Depress the priority of
the calling thread in order to force a thread in a lower priority
queue to run when I call into the scheduler? The code is simply broken,
on any operating system. It just so happens that it is more broken
<dillon at xxxxxxxxxxxxx>
More information about the Bugs