From: Andy Whitcroft <apw@shadowen.org>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] linear reclaim core
Date: Sun, 10 Sep 2006 03:23:40 +0100 [thread overview]
Message-ID: <4503772C.5010105@shadowen.org> (raw)
In-Reply-To: <20060908114114.87612de3.akpm@osdl.org>
Andrew Morton wrote:
> On Fri, 8 Sep 2006 13:27:18 +0100
> Andy Whitcroft <apw@shadowen.org> wrote:
>
>> When we are out of memory of a suitable size we enter reclaim.
>> The current reclaim algorithm targets pages in LRU order, which
>> is great for fairness but highly unsuitable if you desire pages at
>> higher orders. To get pages of higher order we must shoot down a
>> very high proportion of memory; >95% in a lot of cases.
>>
>> This patch introduces an alternative algorithm used when requesting
>> higher order allocations. Here we look at memory in ranges at the
>> order requested. We make a quick pass to see if all pages in that
>> area are likely to be reclaimed, only then do we apply reclaim to
>> the pages in the area.
>>
>> Testing in combination with fragmentation avoidance shows
>> significantly improved chances of a successful allocation at
>> higher order.
>
> I bet it does.
>
> I'm somewhat surprised at the implementation. Would it not be sufficient
> to do this within shrink_inactive_list()? Something along the lines of:
>
> - Pick tail page off LRU.
>
> - For all "neighbour" pages (alignment == 1<<order, count == 1<<order)
>
> - If they're all PageLRU and !PageActive, add them all to page_list for
> possible reclaim
>
> And, in shrink_active_list:
>
> - Pick tail page off LRU
>
> - For all "neighbour" pages (alignment == 1<<order, count == 1<<order)
>
> If they're all PageLRU, put all the active pages in this block onto
> l_hold for possible deactivation.
>
>
> Maybe all that can be done in isolate_lru_pages().
When we started out down this road we though we needed to scan linearly
too due to the buddy marking scheme. Now that we're at this end of the
road we know thats pretty easy to fix, we're already considering merging
the two reclaims anyhow.
Probabally this would do something pretty similar. It feels at a quick
glance as it its going to have slightly different semantics, but that
may be better or worse.
I'll go try it out and see how it looks.
Thanks for reading.
-apw
--
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-09-10 2:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-08 12:24 [PATCH 0/5] Linear reclaim V1 Andy Whitcroft
2006-09-08 12:25 ` [PATCH 1/5] linear reclaim add order to reclaim path Andy Whitcroft
2006-09-08 12:25 ` [PATCH 2/5] linear reclaim export page_order and family Andy Whitcroft
2006-09-08 12:26 ` [PATCH 3/5] linear reclaim pull out unfreeable page return Andy Whitcroft
2006-09-08 12:26 ` [PATCH 4/5] linear reclaim add pfn_valid_within for zone holes Andy Whitcroft
2006-09-08 12:27 ` [PATCH 5/5] linear reclaim core Andy Whitcroft
2006-09-08 18:41 ` Andrew Morton
2006-09-10 2:23 ` Andy Whitcroft [this message]
2006-09-10 9:51 ` Peter Zijlstra
2006-09-10 17:09 ` [PATCH] lumpy reclaim -v2 Peter Zijlstra
2006-09-10 23:45 ` [PATCH 5/5] linear reclaim core Jörn Engel
2006-09-11 0:40 ` Andrew Morton
2006-09-11 7:33 ` Jörn Engel
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=4503772C.5010105@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@osdl.org \
--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