DragonFly BSD
DragonFly bugs List (threaded) for 2006-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Very high CPU usage running growisofs

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 18 Sep 2006 10:40:11 -0700 (PDT)

: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
    on DragonFly.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]