Re: high system cpu load during intense disk i/o

[Dimitrios Apostolou <jimis@gmx.net>]

On Sunday 05 August 2007 20:58:15 Rafał Bilski wrote:
> > Hello again,
>
> Hi!
>
> > was my report so complicated? Perhaps I shouldn't have included so many
> > oprofile outputs. Anyway, if anyone wants to have a look, the most
> > important is two_discs_bad.txt oprofile output, attached on my original
> > message. The problem is 100% reproducible for me so I would appreciate if
> > anyone told me he has similar experiences.
>
> Probably nobody replied to Your message because people at this list think
> that Your problem isn't kernel related. In this moment I'm using "Arch
> Linux" too, so I checked /etc/cron directory. There simple jobs You are
> talking about are not so simple:
> - update the "locate" database,
> - update the "whatis" database.
> Both jobs are scaning "/" partition. I don't know how dcron works, but I
> can imagine situation in which it is polling cron.daily and says: "hey it
> wasn't done today yet" and it is starting same jobs over and over again.
> More and more tasks scans the "/" partition and in result access is slower
> and slower.

Hello and thanks for your reply. 

The cron job that is running every 10 min on my system is mpop (a 
fetchmail-like program) and another running every 5 min is mrtg. Both 
normally finish within 1-2 seconds. 

The fact that these simple cron jobs don't finish ever is certainly because of 
the high system CPU load. If you see the two_discs_bad.txt which I attached 
on my original message, you'll see that *vmlinux*, and specifically the 
*scheduler*, take up most time. 

And the fact that this happens only when running two i/o processes but when 
running only one everything is absolutely snappy (not at all slow, see 
one_disc.txt), makes me sure that this is a kernel bug. I'd be happy to help 
but I need some guidance to pinpoint the problem. 


Thanks, 
Dimitris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/