From: Andrew Morton <akpm@osdl.org>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: colpatch@us.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC] Make balance_dirty_pages zone aware (1/2)
Date: Mon, 24 Nov 2003 17:05:06 -0800 [thread overview]
Message-ID: <20031124170506.4024bb30.akpm@osdl.org> (raw)
In-Reply-To: <39670000.1069719009@flay>
"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> > What trouble?
>
> Well ... not so sure of this as I once was ... so be gentle with me ;-)
> But if the system has been running for a while, memory is full of pagecache,
> etc. We try to allocate from the local node, fail, and fall back to the
> other nodes, which are all full as well. Then we wake up kswapd, but all
> pages in this node are dirty, so we block for ages on writeout, making
> mem allocate really latent and slow (which was presumably what
> balance_dirty_pages was there to solve in the first place).
It is possible. You'd be pretty unlucky to dirty so much lowmem when there
is such a huge amount of highmem floating about, but yes, if you tried hard
enough...
I have a feeling that some observed problem must have prompted this coding
frenzy from Matthew. Surely some problem was observed, and this patch
fixed it up??
> > If we make the dirty threshold a proportion of the initial amount of free
> > memory in ZONE_NORMAL, as is done in 2.4 it will not be possible to fill
> > any node with dirty pages.
>
> True. But that seems a bit extreme for a system with 64GB of RAM, and only
> 896Mb in ZONE_NORMAL ;-) Doesn't really seem like the right way to fix it.
>
Increasing /proc/sys/vm/lower_zone_protection can be used to teach the VM
to not use lowmem for pagecache. Does this solve the elusive problem too?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@osdl.org>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: colpatch@us.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC] Make balance_dirty_pages zone aware (1/2)
Date: Mon, 24 Nov 2003 17:05:06 -0800 [thread overview]
Message-ID: <20031124170506.4024bb30.akpm@osdl.org> (raw)
In-Reply-To: <39670000.1069719009@flay>
"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> > What trouble?
>
> Well ... not so sure of this as I once was ... so be gentle with me ;-)
> But if the system has been running for a while, memory is full of pagecache,
> etc. We try to allocate from the local node, fail, and fall back to the
> other nodes, which are all full as well. Then we wake up kswapd, but all
> pages in this node are dirty, so we block for ages on writeout, making
> mem allocate really latent and slow (which was presumably what
> balance_dirty_pages was there to solve in the first place).
It is possible. You'd be pretty unlucky to dirty so much lowmem when there
is such a huge amount of highmem floating about, but yes, if you tried hard
enough...
I have a feeling that some observed problem must have prompted this coding
frenzy from Matthew. Surely some problem was observed, and this patch
fixed it up??
> > If we make the dirty threshold a proportion of the initial amount of free
> > memory in ZONE_NORMAL, as is done in 2.4 it will not be possible to fill
> > any node with dirty pages.
>
> True. But that seems a bit extreme for a system with 64GB of RAM, and only
> 896Mb in ZONE_NORMAL ;-) Doesn't really seem like the right way to fix it.
>
Increasing /proc/sys/vm/lower_zone_protection can be used to teach the VM
to not use lowmem for pagecache. Does this solve the elusive problem too?
--
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 prev parent reply other threads:[~2003-11-25 0:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-22 0:49 [RFC] Make balance_dirty_pages zone aware (1/2) Matthew Dobson
2003-11-23 22:36 ` Andrew Morton
2003-11-23 22:36 ` Andrew Morton
2003-11-24 15:36 ` Martin J. Bligh
2003-11-24 15:36 ` Martin J. Bligh
2003-11-24 18:00 ` Andrew Morton
2003-11-24 18:00 ` Andrew Morton
2003-11-25 0:10 ` Martin J. Bligh
2003-11-25 0:10 ` Martin J. Bligh
2003-11-25 1:05 ` Andrew Morton [this message]
2003-11-25 1:05 ` Andrew Morton
2003-11-25 4:58 ` Martin J. Bligh
2003-11-25 4:58 ` Martin J. Bligh
2003-11-25 5:14 ` Andrew Morton
2003-11-25 5:14 ` Andrew Morton
2003-11-25 5:23 ` Andrew Morton
2003-11-25 5:23 ` 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=20031124170506.4024bb30.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=colpatch@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@aracnet.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.