linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrew Morton <akpm@osdl.org>, colpatch@us.ibm.com
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@digeo.com
Subject: Re: [RFC] Make balance_dirty_pages zone aware (1/2)
Date: Mon, 24 Nov 2003 07:36:43 -0800	[thread overview]
Message-ID: <1034580000.1069688202@[10.10.2.4]> (raw)
In-Reply-To: <20031123143627.1754a3f0.akpm@osdl.org>

>> Currently the VM decides to start doing background writeback of pages if 
>>  10% of the systems pages are dirty, and starts doing synchronous 
>>  writeback of pages if 40% are dirty.  This is great for smaller memory 
>>  systems, but in larger memory systems (>2GB or so), a process can dirty 
>>  ALL of lowmem (ZONE_NORMAL, 896MB) without hitting the 40% dirty page 
>>  ratio needed to force the process to do writeback. 
> 
> Yes, it has been that way for a year or so.  I was wondering if anyone
> would hit any problems in practice.  Have you hit any problem in practice?
> 
> I agree that the per-zonification of this part of the VM/VFS makes some
> sense, although not _complete_ sense, because as you've seen, we need to
> perform writeout against all zones' pages if _any_ zone exceeds dirty
> limits.  This could do nasty things on a 1G highmem machine, due to the
> tiny highmem zone.  So maybe that zone should not trigger writeback.
> 
> However the simplest fix is of course to decrease the default value of the
> dirty thresholds - put them back to the 2.4 levels.  It all depends upon
> the nature of the problems which you have been observing?

I'm not sure that'll fix the problem for NUMA boxes, which is where we 
started. When any node fills up completely with dirty pages (which would
only require one process doing a streaming write (eg an ftp download),
it seems we'll get into trouble. If we change the thresholds from 40% to
20%, that just means you need a slightly larger system to trigger it,
it never fixes the problem ;-(

M.

--
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-11-24 15:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-22  0:49 Matthew Dobson
2003-11-23 22:36 ` Andrew Morton
2003-11-24 15:36   ` Martin J. Bligh [this message]
2003-11-24 18:00     ` Andrew Morton
2003-11-25  0:10       ` Martin J. Bligh
2003-11-25  1:05         ` Andrew Morton
2003-11-25  4:58           ` Martin J. Bligh
2003-11-25  5:14             ` 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='1034580000.1069688202@[10.10.2.4]' \
    --to=mbligh@aracnet.com \
    --cc=akpm@digeo.com \
    --cc=akpm@osdl.org \
    --cc=colpatch@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --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