linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: lwoodman@redhat.com, kosaki.motohiro@jp.fujitsu.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, aarcange@redhat.com
Subject: Re: [PATCH] vmscan: limit concurrent reclaimers in shrink_zone
Date: Mon, 14 Dec 2009 09:52:09 -0500	[thread overview]
Message-ID: <4B265119.6090901@redhat.com> (raw)
In-Reply-To: <20091214131444.GA8990@infradead.org>

On 12/14/2009 08:14 AM, Christoph Hellwig wrote:
> On Thu, Dec 10, 2009 at 06:56:26PM -0500, Rik van Riel wrote:

>> It should be possible to avoid both of those issues at once, by
>> simply limiting how many processes are active in the page reclaim
>> code simultaneously.
>>
>
> This sounds like a very good argument against using direct reclaim at
> all.

Not completely possible.  Processes that call try_to_free_pages
without __GFP_FS or __GFP_IO in their gfp_flags may be holding
some kind of lock that kswapd could end up waiting on.

That means those tasks cannot wait on kswapd, because a deadlock
could happen.

Having said that, maybe we can get away with making direct
reclaim a limited subset of what it does today.  Kswapd could
be the only process scanning and unmapping ptes, submitting
IOs and scanning the active list.  Direct reclaim could limit
itself to reclaiming clean inactive pages and sleeping in
congestion_wait().

-- 
All rights reversed.

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

      parent reply	other threads:[~2009-12-14 14:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-10 23:56 Rik van Riel
2009-12-11  2:03 ` Minchan Kim
2009-12-11  3:19   ` Rik van Riel
2009-12-11  3:43     ` Minchan Kim
2009-12-11 12:07   ` Larry Woodman
2009-12-11 13:41     ` Minchan Kim
2009-12-11 13:51       ` Rik van Riel
2009-12-11 14:08         ` Minchan Kim
2009-12-11 13:48     ` Rik van Riel
2009-12-11 21:24   ` Rik van Riel
2009-12-11 11:49 ` Larry Woodman
2009-12-14 13:08 ` Andi Kleen
2009-12-14 14:23   ` Larry Woodman
2009-12-14 16:19     ` Andi Kleen
2009-12-14 14:40   ` Rik van Riel
2009-12-14 13:14 ` Christoph Hellwig
2009-12-14 14:22   ` Larry Woodman
2009-12-14 14:52   ` Rik van Riel [this message]

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=4B265119.6090901@redhat.com \
    --to=riel@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lwoodman@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox