From: Ross Biro <rossb@google.com>
To: Linux-MM@kvack.org
Subject: [BUG 2.4] Buffers Span Zones
Date: Wed, 30 Apr 2003 10:25:47 -0700 [thread overview]
Message-ID: <3EB0071B.2020308@google.com> (raw)
This is probably old hat to all of you, but...
I mentioned this on the LKML, but didn't get a response, so I thought I
would mention it here. It appears that in the 2.4 kernels, kswapd is
not aware that buffer heads can be in one zone while the buffers
themselves are in another zone. This can lead to fake out of memory
messages when lowmem is under preasure and highmem is not.
I believe something like
/* Buffers span classzones because heads are low and
the buffer itself may be elsewhere. */
if (!memclass(page->zone, classzone)) {
struct buffer_head *bh;
int zonebuffers = 0;
if (!page->buffers)
continue;
bh = page->buffers;
do {
if (memclass(virt_to_page(bh)->zone,
classzone)) {
zonebuffers=1;
break;
}
bh = bh->b_this_page;
} while (bh != page->buffers);
if (!zonebuffers)
continue;
}
in shrink cache in place of
if (!memclass(page->zone, classzone)) {
continue;
}
To keep from killing the page cache, after the buffer heads are freed, I
repeate the check
if (!memclass(page->zone, classzone)) {
continue;
}
It also appears that in buffer.c balance_dirty_state really needs to be
zone aware as well. It might also be nice to replace many of the
current->policy |= YIELD; schedule(); pairs with real waits for memory
to free up a bit. If dirty pages or associated structures are filling
up most of the memory, then the problem will go away if we just wait a bit.
I've found that changing PAGE_OFFSET to reduce the amount of lowmem has
been a very good way to exercies the VM. I've been able to cause all
sorts of interesting problems by having ~20M of lowmem and 3G of
highmem. I assume that many of these problems would occur on systems
with 1G of lowmem and 16-20G of highmem.
Please CC me on any responses.
Ross
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next reply other threads:[~2003-04-30 17:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-30 17:25 Ross Biro [this message]
2003-04-30 20:24 ` Martin J. Bligh
2003-05-01 9:45 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EB0071B.2020308@google.com \
--to=rossb@google.com \
--cc=Linux-MM@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox