linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

             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