Running with 2.4.20 and the early feb xfs patches, still have debug
enabled....(maybe that's it?)....
But, running two long-running tar/bzip2 routines (mach=2xP3-1GB)...did
a chmod/chgrp -R in a directory tree that has about 185,000
files....
Seemed to take a long time. I'm used to the first of the pair
taking a while if they aren't in cache. But the 2nd did as well...
looked at top and saw:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
9 root 20 0 0 0 0 RW 96.8 0.0 7:58 pagebuf/0
10 root 20 0 0 0 0 SW 79.3 0.0 7:47 pagebuf/1
7 root 20 0 0 0 0 DW 18.0 0.0 7:31 kupdated
16415 root 15 0 556 556 456 D 2.8 0.0 1:25 chmod
14275 root 16 4 7784 7784 352 R N 1.7 0.7 114:08 bzip2
14405 root 17 12 7784 7784 352 R N 0.9 0.7 67:36 bzip2
16418 root 11 0 1032 1032 820 R 0.3 0.1 0:00 top
---
Wow! ... seems like alot of overhead for a chmod running on one
disk (SCSI). The tars were executing on a separate disk/IDE.
Just a WAG, but I'm guessing this isn't normal behavior?
I did dump /proc/meminfo, and slabinfo (included below) immediately
after the event.
System has been up for almost 7 days now, so could be some housekeeping
is broken somewhere, perhaps a side effect only produced with
debugging enabled? Dunno -- Very strange.
meminfo:
total: used: free: shared: buffers: cached:
Mem: 1056473088 1047224320 9248768 0 0 402280448
Swap: 271425536 16781312 254644224
MemTotal: 1031712 kB
MemFree: 9032 kB
MemShared: 0 kB
Buffers: 0 kB
Cached: 391020 kB
SwapCached: 1832 kB
Active: 129052 kB
Inactive: 306576 kB
HighTotal: 131064 kB
HighFree: 1760 kB
LowTotal: 900648 kB
LowFree: 7272 kB
SwapTotal: 265064 kB
SwapFree: 248676 kB
slabinfo:
....was going to include it...but the colums are waAay wide and will
certainly get malformed, so will attach it -- hopefully it will be
decipherable.
slabinfo.txt
Description: Text document
|