linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Ravikiran G Thirumalai <kiran@scalex86.org>,
	linux-mm@kvack.org, shai@scalex86.org
Subject: Re: [rfc] [patch] mm: zone_reclaim fix for pseudo file systems
Date: Mon, 30 Jul 2007 22:33:03 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0707302224190.30889@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20070730221736.ccf67c86.akpm@linux-foundation.org>

On Mon, 30 Jul 2007, Andrew Morton wrote:

> Nonsense.  The VM used to handle it just fine.  That's what I wrote the
> all_unreclaimable logic *for*.  It wasn't just added as typing practice.

That is if the whole zone is unreclaimable. The problems that we want to 
solve are due to parts of a zone being unreclaimable and due to the VM 
counters giving an inaccurate picture of the memory situation.

> Here's the changelog, from 22 Nov 2002:
> 
> 	[PATCH] handle zones which are full of unreclaimable pages
> 	
> 	This patch is a general solution to the situation where a zone is full
> 	of pinned pages.
> 	
> 	This can come about if:
> 	
> 	a) Someone has allocated all of ZONE_DMA for IO buffers
> 	
> 	b) Some application is mlocking some memory and a zone ends up full
> 	   of mlocked pages (can happen on a 1G ia32 system)
> 	
> 	c) All of ZONE_HIGHMEM is pinned in hugetlb pages (can happen on 1G
> 	   machines)
> 	
> 	We'll currently burn 10% of CPU in kswapd when this happens, although
> 	it is quite hard to trigger.
> 	
> 	The algorithm is:
> 	
> 	- If page reclaim has scanned 2 * the total number of pages in the
> 	  zone and there have been no pages freed in that zone then mark the
> 	  zone as "all unreclaimable".
> 	
> 	- When a zone is "all unreclaimable" page reclaim almost ignores it.
> 	  We will perform a "light" scan at DEF_PRIORITY (typically 1/4096'th of
> 	  the zone, or 64 pages) and then forget about the zone.
> 	
> 	- When a batch of pages are freed into the zone, clear its "all
> 	  unreclaimable" state and start full scanning again.  The assumption
> 	  being that some state change has come about which will make reclaim
> 	  successful again.
> 	
> 	  So if a "light scan" actually frees some pages, the zone will revert to
> 	  normal state immediately.
> 	
> 	So we're effectively putting the zone into "low power" mode, and lightly
> 	polling it to see if something has changed.
> 	
> 	The code works OK, but is quite hard to test - I mainly tested it by
> 	pinning all highmem in hugetlb pages.
> 
> 
> See?  "general".

Nope. Its a special situation in which the whole zone has become 
unhandleable by the reclaim logic so it gives up and waits for things 
somehow to get better. During that time we cannot allocate from a zone 
which typically makes a vital zone or a node unusuable. In a NUMA 
configuration performance degrades in unacceptable ways.

What we want is to remove the unreclaimable pages from the LRU and have 
reclaim continue on the remainder of the zone.

> No, let us not.  If the existing crap isn't working as it should (and as it
> used to) let us first fix (or at least understand) that before adding more
> crap.
> 
> No?

The all_reclaimable logic is different. It was never been designed to 
remove the unreclaimable pages.

--
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>

  reply	other threads:[~2007-07-31  5:33 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-27 23:27 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 [this message]
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
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=Pine.LNX.4.64.0707302224190.30889@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=akpm@linux-foundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox