From: "Martin J. Bligh" <mbligh@google.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management <linux-mm@kvack.org>
Subject: Re: [PATCH] Use min of two prio settings in calculating distress for reclaim
Date: Mon, 16 Oct 2006 23:43:29 -0700 [thread overview]
Message-ID: <45347B91.20404@google.com> (raw)
In-Reply-To: <45347951.3050907@yahoo.com.au>
Nick Piggin wrote:
> Martin Bligh wrote:
>
>> Another bug is that if try_to_free_pages / balance_pgdat are called
>> with a gfp_mask specifying GFP_IO and/or GFP_FS, they may reclaim
>> the requisite number of pages, and reset prev_priority to DEF_PRIORITY.
>>
>> However, another reclaimer without those gfp_mask flags set may still
>> be struggling to reclaim pages. The easy fix for this is to key the
>> distress calculation not off zone->prev_priority, but also take into
>> account the local caller's priority by using:
>> min(zone->prev_priority, sc->priority)
>
>
> Does it really matter who is doing the actual reclaiming? IMO, if the
> non-crippled (GFP_IO|GFP_FS) reclaimer is making progress, the other
> guy doesn't need to start swapping, and should soon notice that some
> pages are getting freed up.
That's not what happens though. We walk down the priorities, fail to
reclaim anything (in this case, move anything from active to inactive)
and the OOM killer fires. Perhaps the other pages being freed are
being stolen ... we're in direct reclaim here. we're meant to be
getting our own pages.
Why would we ever want distress to be based off a priority that's
higher than our current one? That's just silly.
> Workloads where non GFP_IO or GFP_FS reclaimers are having a lot of
> trouble indicates that either it is very swappy or page writeback has
> broken down and lots of dirty pages are being reclaimed off the LRU.
> In either case, they are likely to continue to have problems, even if
> they are now able to unmap the odd page.
We scanned 122,000 odd pages. Of which we skipped over over 100,000
of them because they were mapped, and we didn't think we had to try
very hard, because distress was 0.
> What are the empirical effects of this patch? What's the numbers? And
> what have you done to akpm? ;)
Showed him a real trace of a production system blowing up?
Demonstrated that the current heuristics are broken?
That sort of thing.
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-10-17 6:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-17 1:30 Martin Bligh
2006-10-17 6:33 ` Nick Piggin
2006-10-17 6:43 ` Martin J. Bligh [this message]
2006-10-17 6:56 ` Nick Piggin
2006-10-17 13:52 ` Martin J. Bligh
2006-10-17 16:43 ` Nick Piggin
2006-10-17 16:58 ` Martin Bligh
2006-10-17 17:14 ` Nick Piggin
2006-10-17 6:50 ` 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=45347B91.20404@google.com \
--to=mbligh@google.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
/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