Bug 14648

Summary:	[2.6.x regression] proc fs busy/usage statistics during IO operations makes no sense
Product:	Other	Reporter:	Artem S. Tashkinov (aros)
Component:	Other	Assignee:	other_other
Status:	RESOLVED INVALID
Severity:	normal
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:		Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:	14531
Bug Blocks:

Description Artem S. Tashkinov 2009-11-20 19:37:53 UTC

I really dislike the fact that during intense IO operations (like copying a file from one partition to another one) you cannot see the actual CPU usage because kernel (via proc fs) reports that one of the CPUs is 100% busy. Most people, when faced with such statistics, will judge with all confidence, that CPU is indeed 100% busy which is not true.

One could think that this is probably a userspace bug, but I tend not to think this way, because both top and htop utitities report the same data. Furthermore, this simple test:

cat big_file > /dev/null

will raise load average to 1.00 which means that at least one of the CPUs in a system is 100% busy and load average is a _direct_ kernel counter, so, top and htop cannot be wrong.

That doesn't make sense. Please, fix this bug. If a CPU is indeed busy waiting for IO operations to complete, then a real IO wait time should be reported.

P.S. Kernel 2.4.x did not have this problem.

Comment 1 Artem S. Tashkinov 2010-05-27 19:24:24 UTC

Gnome System Monitor doesn't have this problem, closing.