Very high CPU usage running growisofs

Steve O'Hara-Smith steve at sohara.org
Tue Sep 19 05:31:06 PDT 2006


On Mon, 18 Sep 2006 17:50:33 +0200
Joerg Sonnenberger <joerg at xxxxxxxxxxxxxxxxx> wrote:

> 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
> loop.

	I had a strong suspicion that it wasn't an ideal solution. OTOH it
does the job of making the application work and follows an old lesson that
I recall, namely that a small sleep often improves the performance of a
wait loop.

> 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.

	I have done some searching and I can't find any reports of similar
performance issues on other OSs so presumably the trip through the kernel
on other OSs is somehow reducing this problem to acceptable level. That
being said putting a usleep(10) instead of the usleep(10000) in only
doubled the write speed and left the CPU consumption at 75% so it seems to
need more than just a trip through kernel space to make it work.

	Anyway for now I have a hack that makes things work.

-- 
C:>WIN                                      |   Directable Mirror Arrays
The computer obeys and wins.                | A better way to focus the sun
You lose and Bill collects.                 |    licences available see
                                            |    http://www.sohara.org/





More information about the Bugs mailing list