From cmaiolino at maiolino.org Thu Jul 21 13:38:58 2011 From: cmaiolino at maiolino.org (Carlos Maiolino) Date: Thu, 21 Jul 2011 10:38:58 -0300 Subject: High CPU Utilization When Copying to Ext4 In-Reply-To: <341DAA96EE3A8444B6E4657BE8A846EA4B3DA126FE@NDJSSCC06.ndc.nasa.gov> References: <341DAA96EE3A8444B6E4657BE8A846EA4B3DA126FE@NDJSSCC06.ndc.nasa.gov> Message-ID: <20110721133858.GA2479@pegasus.maiolino.org> > I'm copying terabytes of data from an ext3 file system to a new ext4 file system. I'm seeing high CPU usage from the processes flush-253:2, kworker-3:0, kworker-2:2, kworker-1:1, and kworker-0:0. Does anyone on the list have any idea what these processes do, why they are consuming so much cpu time and if there is something that can be done about it? This is using Fedora 15. > Hi, the flush thread is used to flush page cache out to disk, and kworker threads, iirc are general threads responsible to complete workqueue jobs (see workqueues in kernel). Looks like it's behaving as expected, once you're copying terabytes of data, the flush will have to do a lot of job to send cached data to disk, and kworker threads should be being used to do some kind of job related. I found this in kernel documentation at linux-2.6/Documentation/workqueue.txt: ------------------------------------- If kworkers are going crazy (using too much cpu), there are two types of possible problems: 1. Something beeing scheduled in rapid succession 2. A single work item that consumes lots of cpu cycles The first one can be tracked using tracing: $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt (wait a few secs) ^C If something is busy looping on work queueing, it would be dominating the output and the offender can be determined with the work item function. For the second type of problems it should be possible to just check the stack trace of the offending worker thread. $ cat /proc/THE_OFFENDING_KWORKER/stack The work item's function should be trivially visible in the stack trace. ------------------------------------ Cheers. -- -Carlos