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

From: Dimitrios Apostolou
Date: Sun Aug 05 2007 - 14:44:43 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/