2002-10-23 12:07:39

by bert hubert

[permalink] [raw]
Subject: 2.5.44 io accounting weirdness, bi & bo swapped?

It appears as if the kernel does its accounting wrong in some places. For
example, with procps 3.0.4, dd if=/dev/zero of=/mnt/100mb bs=1024
count=100000 causes large 'bi' readings:

$ vmstat 1
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 14340 7356 2372 146784 4 2 332 290 1102 223 2 24 74
0 0 0 14340 7344 2372 146784 0 0 0 0 1013 87 1 0 99
0 0 0 14340 7332 2372 146784 0 0 0 0 1011 233 1 1 98
2 0 1 14320 3932 2292 150428 0 0 5504 144 2104 333 3 65 32
2 0 1 14320 4448 1772 150436 0 0 7208 0 1999 89 2 98 0
3 0 3 14320 2812 1740 152060 0 0 8664 20 2541 372 4 87 9

However, mmapping a file and touching 100mb of pages does the following,
which looks sane:

$ vmstat 1
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 14320 9956 1940 144660 0 0 0 0 1017 155 1 0 99
1 0 1 14320 7972 1952 146560 0 0 0 1912 1279 277 2 53 45
0 1 0 14320 4048 1744 150708 0 0 360 6024 1858 412 1 99 0
1 0 1 14320 4096 1612 151020 0 0 0 5252 1741 338 2 98 0
1 0 1 14320 3396 1612 151864 0 0 0 7144 2057 896 2 97 1
1 0 1 14320 3696 1612 151644 0 0 0 7192 2087 982 1 99 0
1 0 1 14320 3240 1548 152220 0 0 4 6940 2062 984 2 98 0
0 0 0 14320 2472 1544 153072 0 0 0 7008 2059 1010 2 98 0
0 0 0 14320 2464 1544 153072 0 0 0 0 1005 57 1 1 98

Interestingly, running sync then causes this, which does not look sane:

0 0 0 14316 3792 1680 151688 0 0 0 0 1014 146 1 2 97
3 0 3 14316 3572 1692 151696 0 0 10456 12 3510 260 2 65 33
1 0 2 14316 3456 1700 151696 0 0 12516 0 2136 164 4 96 0
2 0 2 14316 3452 1700 151696 0 0 6412 0 2983 66 3 97 0
6 0 4 14316 3120 1700 151696 0 0 26152 0 6880 71 1 99 0
1 0 1 14316 3488 1708 151704 0 0 14664 12 3859 94 2 98 0
11 0 5 14316 3112 1708 151704 0 0 29892 0 7747 28 1 99 0
1 0 0 14316 3732 1728 151704 0 0 72 0 1049 176 1 4 95
1 0 0 14316 3720 1728 151704 0 0 0 0 1068 172 1 0 99

This shown with 'vmloader':
vmloader> mmap /mnt/blah
mmap()ing 375000 pages (1500 mbytes). Done
vmloader> touch 100
Touching from mbyte 0 to 100, 25000 pages. Done
vmloader> quit
$ sync

http://ds9a.nl/vmloader-0.1.tar.gz

Regards,

bert

--
http://www.PowerDNS.com Versatile DNS Software & Services
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO


2002-10-23 12:42:10

by bert hubert

[permalink] [raw]
Subject: Re: 2.5.44 io accounting weirdness, bi & bo swapped?

On Wed, Oct 23, 2002 at 02:13:47PM +0200, bert hubert wrote:
> It appears as if the kernel does its accounting wrong in some places. For
> example, with procps 3.0.4, dd if=/dev/zero of=/mnt/100mb bs=1024
> count=100000 causes large 'bi' readings:

My bad. In this case, what I thought of as sane:

> However, mmapping a file and touching 100mb of pages does the following,
> which looks sane:
>
> r b w swpd free buff cache si so bi bo in cs us sy id
> 1 0 1 14320 7972 1952 146560 0 0 0 1912 1279 277 2 53 45

Is not. Touching a page entails reading it. In Albert's procps with 2.5.44,
bi and bo are reversed. Rik's vmstat does report things correctly.

Because I saw vmstat sometimes being right and sometimes being wrong, I
derived that is was the kernel that was at fault.

Perhaps Albert's procps isn't ready for 2.5.44?

Regards,

bert hubert

--
http://www.PowerDNS.com Versatile DNS Software & Services
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO

2002-10-23 14:51:12

by Rik van Riel

[permalink] [raw]
Subject: Re: 2.5.44 io accounting weirdness, bi & bo swapped?

On Wed, 23 Oct 2002, bert hubert wrote:

> Is not. Touching a page entails reading it. In Albert's procps with 2.5.44,
> bi and bo are reversed. Rik's vmstat does report things correctly.

> Perhaps Albert's procps isn't ready for 2.5.44?

I suspect it's just a simple typo somewhere. Maybe Albert can't
run 2.5 on his computer so he didn't get around to testing ?

Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>

2002-10-23 22:20:07

by Albert D. Cahalan

[permalink] [raw]
Subject: Re: 2.5.44 io accounting weirdness, bi & bo swapped?

bert hubert writes:
> On Wed, Oct 23, 2002 at 02:13:47PM +0200, bert hubert wrote:

>> It appears as if the kernel does its accounting wrong in
>> some places. For example, with procps 3.0.4, dd if=/dev/zero
>> of=/mnt/100mb bs=1024 count=100000 causes large 'bi' readings:
>
> My bad. In this case, what I thought of as sane:
...
> Is not. Touching a page entails reading it. In Albert's procps
> with 2.5.44, bi and bo are reversed. Rik's vmstat does report
> things correctly.

That's fixed now. Rik's vmstat is not correct; according to his
documentation "bo" means "blocks in" and "bi" means "blocks out",
but that's not what his vmstat does. :-)

The only Linux vmstat that runs according to spec:

http://procps.sf.net/
http://procps.sf.net/procps-3.0.5.tar.gz

---------------- recent changes -----------------

procps-3.0.4 --> procps-3.0.5

top tolerates super-wide displays
better (?) RPM generation
XConsole and top.desktop removed
old build system removed
code cleanup
pgrep and pkill get "-o" (oldest matching process)
had vmstat "bi" and "bo" output interchanged on 2.5.xx
fix man page tbl directives
top man page cleaned up

procps-3.0.3 --> procps-3.0.4

make top go faster
Linux 2.2.xx ELF note warning removed
only show IO-wait on recent kernels
fix top's SMP stats
fix top for "dumb" and "vt510" terminals
in top, limit the priority values to -99 ... 99

procps-3.0.2 --> procps-3.0.3

more "make install" fixes
lib CFLAGS working again
top.1 codes fixed
bad (int*) cast in top removed
top runs faster
libproc memory corruption fixed
rant moved out of top.1 man page
ability to SKIP installing things
fixed ps --sort crash