linux-kernel - Re: Why is deleting (or reading) files not counted as IO-Wait in top?

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:	Sat, 5 Jan 2008 17:58:44 +0100
From:	Matthias Schniedermeyer <ms@...d.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, David Chinner <dgc@....com>,
	Timothy Shimmin <tes@....com>
Subject: Re: Why is deleting (or reading) files not counted as IO-Wait in
	top?

On 05.01.2008 01:31, Andrew Morton wrote:
> On Wed, 2 Jan 2008 20:35:03 +0100 Matthias Schniedermeyer <ms@...d.de> wrote:
> 
> > Hi
> > 
> > 
> > Currently i'm deleting about 500.000 files on a XFS-filesystem which 
> > takes a few minutes, as i had a top open i saw that 'wa' is shown as 
> > 0.0% (Nothing else running currently) and everything except 'id' is near 
> > the bottom too. Kernel is 2.6.23.11.
> > 
> > So, as 'rm -rf' is essentially a IO (or seek, to be more correct)-bound 
> > task, shouldn't that count as "Waiting for IO"?
> > 
> > The man-page of top says:
> > 'Amount of time the CPU has been waiting for I/O to complete.'
> > 
> > But AFAICT wa only seams to be (ac)counted for writing and not for 
> > reading. I come to that conclusion because, when i fire 'sync' i can see 
> > some percent wa for a few seconds.
> > 
> 
> Yes, you would absolutely expect `rm' to be stuck in D state and
> contributing to both load average and io-wait in this situation.
> 
> I'd think that either XFS is playing games (and it'd take some pretty
> inventive games to do this) or your observations are in error.

I don't think that i could do much wrong(tm).

rm -rf <big dir> (Took >30 minutes to delete)
Everything else was sleeping at the time.

The sleeping processes are the usual handful of about 200 processes, you 
have laying around today. 47 kernel threads, another about 40 or so 
demons, and the rest >100 processes was my KDE-Session (mostly 
'konsole's with bashes inside) with Iceweasel (Firefox) as sugar on top. 
But as i said, there weren't doing anything at all, 'us' peaked at about 
1-1.4 when i watched top.





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

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