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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 5 Aug 2007 21:42:13 +0300
From:	Dimitrios Apostolou <jimis@....net>
To:	Rafał Bilski <rafalbilski@...eria.pl>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: high system cpu load during intense disk i/o

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