From: Andrew Morton <akpm@linux-foundation.org>
To: Ravikiran G Thirumalai <kiran@scalex86.org>
Cc: linux-mm@kvack.org, Christoph Lameter <clameter@engr.sgi.com>,
shai@scalex86.org
Subject: Re: [rfc] [patch] mm: zone_reclaim fix for pseudo file systems
Date: Mon, 30 Jul 2007 18:53:20 -0700 [thread overview]
Message-ID: <20070730185320.8bbfc0ac.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070731013649.GB32468@localdomain>
On Mon, 30 Jul 2007 18:36:49 -0700 Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> On Mon, Jul 30, 2007 at 05:20:07PM -0700, Andrew Morton wrote:
> >On Mon, 30 Jul 2007 17:01:38 -0700
> >Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> >
> >> >The (cheesy) way in which reclaim currently handles this sort of thing is
> >> >to scan like mad, then to eventually set zone->all_unreclaimable. Once
> >> >that has been set, the kernel will reduce the amount of scanning effort it
> >> >puts into that zone by a very large amount. If the zone later comes back
> >> >to life, all_unreclaimable gets cleared and things proceed as normal.
> >>
> >> I see. But this obviously does not work in this case. I have noticed the
> >> process getting into 'system' and staying there for hours. I have never
> >> noticed the app complete. Perhaps because I did not wait long enough.
> >> So do you think a more aggressive auto setting/unsetting of 'all_unreclaimable'
> >> is a better approach?
> >
> >The problem is that __zone_reclaim() doesn't use all_unreclaimable at all.
> >You'll note that all the other callers of shrink_zone() do take avoiding
> >action if the zone is in all_unreclaimable state, but __zone_reclaim() forgot
> >to.
>
> Ummm... zone_reclaim does look at all_unreclaimable:
oh crap then we don't know what's going on. At least, I don't.
> int zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order)
> ...
> ...
> /*
> * Avoid concurrent zone reclaims, do not reclaim in a zone that
> * does
> * not have reclaimable pages and if we should not delay the
> * allocation
> * then do not scan.
> */
> if (!(gfp_mask & __GFP_WAIT) ||
> zone->all_unreclaimable ||
> atomic_read(&zone->reclaim_in_progress) > 0 ||
> (current->flags & PF_MEMALLOC))
> return 0;
>
> I guess it is not being set correctly for unreclaimable (pseudo fs) pages.
It doesn't care what type of page we're looking at.
umm, OK, perhaps the problem is that all_unreclaimable isn't getting set,
rather than that we aren't testing it.
Note that shrink_zones() and balance_pgdat() will set all_unreclaimable if
things get screwed up, but afaict zone_reclaim() doesn't.
--
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-07-31 1:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-27 23:27 [rfc] [patch] mm: zone_reclaim fix for pseudo file systems Ravikiran G Thirumalai
2007-07-30 18:12 ` Christoph Lameter
2007-07-30 20:23 ` Andrew Morton
2007-07-30 20:31 ` Christoph Lameter
2007-07-30 21:12 ` Lee Schermerhorn
2007-07-31 0:01 ` Ravikiran G Thirumalai
2007-07-31 0:20 ` Andrew Morton
2007-07-31 0:27 ` Christoph Lameter
2007-07-31 1:06 ` Andrew Morton
2007-07-31 1:52 ` Christoph Lameter
2007-07-31 1:56 ` Ravikiran G Thirumalai
2007-07-31 2:01 ` Christoph Lameter
2007-07-31 2:27 ` Andrew Morton
2007-07-31 2:36 ` Christoph Lameter
2007-07-31 4:47 ` Andrew Morton
2007-07-31 5:00 ` Christoph Lameter
2007-07-31 5:17 ` Andrew Morton
2007-07-31 5:33 ` Christoph Lameter
2007-07-31 5:58 ` Andrew Morton
2007-07-31 6:09 ` Christoph Lameter
2007-07-31 6:18 ` Andrew Morton
2007-07-31 19:35 ` Christoph Lameter
2007-07-31 19:46 ` Andrew Morton
2007-07-31 19:50 ` Christoph Lameter
2007-07-31 8:27 ` Ravikiran G Thirumalai
2007-07-31 8:35 ` Andrew Morton
2007-07-31 19:30 ` Christoph Lameter
2007-07-31 19:20 ` Christoph Lameter
2007-07-31 7:15 ` Ravikiran G Thirumalai
2007-07-31 19:18 ` Christoph Lameter
2007-07-31 1:36 ` Ravikiran G Thirumalai
2007-07-31 1:53 ` Andrew Morton [this message]
2007-07-31 1:56 ` Christoph Lameter
2007-07-31 2:19 ` Christoph Lameter
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=20070730185320.8bbfc0ac.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=clameter@engr.sgi.com \
--cc=kiran@scalex86.org \
--cc=linux-mm@kvack.org \
--cc=shai@scalex86.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 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.