there's a race somewhere that's causing shrink_mmap to deduct too much
from buffermem, making it go negative. i don't think that it's specific
to a particular driver. i haven't been able to simply and consistently
reproduce the race -- maybe you could come up with some way to do this?
is it specific to how much data you copied, for instance?
On Fri, 6 Aug 1999, Mofeed Shahin wrote:
> First off I will explain what I was doing that caused the problem.
> I was copying a whole CD to the hard-drive. They are both scsi AIC7xxx.
>
> While I was copying I noticed Xosview not looking too healthy so I ran top
> and noticed that the amount of buffer memory was obviously wrong.
>
> here is the vmstat output :
>
> :vmstat
> procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
> 1 0 0 744 2908 4193304 205452 0 0 2 4 52 14 47 0 53
> ^^^^^^^
> Notice the 4.1 GIG of buffer memory.
>
> Also half way through the copy klogd started using up all the CPU time on
> one of the processors.
> Even after the copy had finished klogd was still using up large amounts of
> CPU (100%).
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/