On Thu, 28 May 1998, Hwei Sheng TEOH wrote:
> Hi, sorry if this is doesn't belong to this mailing list, but I've posted to
> the linux newsgroups and was directed here. I think this might be of interest
> to kernel developers.
It certainly is appropriate!
...
> I know it's this process that's thrashing, because the HD stops grinding when
> I issue a 'kill -STOP <pid>', and resumes thrashing when I re-active the
> process using 'kill -CONT <pid>'.
Okay, there are two things I'm curious about: a) what activity of the
program is it that triggers the disk activity: if you could use gdb or
strace to figure out exactly what syscall or approximately what memory
access does it, that would be a great help (also, does vmstat show swap
activity or disk io?). b) What is the output of
cat /proc/meminfo at this time? c) If you do a dd if=/dev/zero
of=/dev/null bs=4096k count=1, does the system revert back to 'silent'
operation? (This trick will only work under 2.0.x) d) Does using one of
the more recent 2.0.34preX kernels? (There are a couple of minor mm
changes.)
Since you've said this process includes running a shell script, are you
sure it's not the system writing out updated atimes of files? If that's
the case then (c) above might make a difference -- the system might be in
a state where it's not allocating additional buffers to delay the writes
(likely if there's been a lot of write activity recently and a lot of
dirty buffers exist, just hit shift+scroll-lock to get the buffer stats).
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu