Badari Pulavarty <[email protected]> wrote:
>
> Here is the data with 5 ext2 filesystems. I also collected /proc/meminfo
> every 5 seconds. As you can see, we seem to dirty 6GB of data in 20
> seconds of starting the test. I am not sure if its bad, since we have
> lots of free memory..
It's bad. The logic in balance_dirty_pages() should block those write()
callers as soon as we hit 40% dirty memory or whatever is in
/proc/sys/vm/dirty_ratio. So something is horridly busted.
Can you try reducing the number of filesystems even further?
Either the underlying block driver is doing something most bizarre to the
VFS or something has gone wrong with the arithmetic in page-writeback.c.
If total_pages or ratelimit_pages are totally wrong or if
get_dirty_limits() is returning junk then we'd be seeing something like
this.
It'll be something simple - if you have time, stick some printks in
balance_dirty_pages(), work out why it is not remaining in that `for' loop
until dirty memory has fallen below the 40%.
I'll take a shot at reproducing this on my 4G x86_64 box, but this is so
grossly wrong that I'm sure it would have been noted before now if it was
commonly happening (famous last words).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |