lkml.org 
[lkml]   [2016]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectFwd: [RFC PATCH 1/3] mm, page_alloc: free HIGHATOMIC page directly to the allocator
Hi,
The original message is somehow determined to be junk mail and
rejected by the system.
Forward this message.

---------- Forwarded message ----------
From: Wenwei Tao <ww.tao0320@gmail.com>
Date: 2016-06-19 10:40 GMT+08:00
Subject: Re: [RFC PATCH 1/3] mm, page_alloc: free HIGHATOMIC page
directly to the allocator
To: Vlastimil Babka <vbabka@suse.cz>
抄送: Wenwei Tao <wwtao0320@163.com>, akpm@linux-foundation.org,
mgorman@techsingularity.net, mhocko@suse.com, rientjes@google.com,
kirill.shutemov@linux.intel.com, iamjoonsoo.kim@lge.com,
izumi.taku@jp.fujitsu.com, Johannes Weiner <hannes@cmpxchg.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org


2016-06-18 18:14 GMT+08:00 Vlastimil Babka <vbabka@suse.cz>:
> On 06/18/2016 11:34 AM, Wenwei Tao wrote:
>> From: Wenwei Tao <ww.tao0320@gmail.com>
>>
>> Some pages might have already been allocated before reserve
>> the pageblock as HIGHATOMIC. When free these pages, put them
>> directly to the allocator instead of the pcp lists since they
>> might have the chance to be merged to high order pages.
>
> Are there some data showing the improvement, or just theoretical?
>

It's just theoretical. I read the mm code and try to understand it,
think this might be an optimization.

>> Signed-off-by: Wenwei Tao <ww.tao0320@gmail.com>
>> ---
>> mm/page_alloc.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 6903b69..19f9e76 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -2412,7 +2412,8 @@ void free_hot_cold_page(struct page *page, bool cold)
>
> The full comment that's here for context:
>
> /*
> * We only track unmovable, reclaimable and movable on pcp lists.
> * Free ISOLATE pages back to the allocator because they are being
> * offlined but treat RESERVE as movable pages so we can get those
> * areas back if necessary. Otherwise, we may have to free
> * excessively into the page allocator
> */
>
> That comment looks outdated as it refers to RESERVE, which was replaced
> by HIGHATOMIC. But there's some reasoning why these pages go to
> pcplists. I'd expect the "free excessively" part isn't as bad as
> highatomic reserves are quite limited. They also shouldn't be used for
> order-0 allocations, which is what this function is about, so I would
> expect both the impact on "free excessively" and the improvement of
> merging to be minimal?
>
>> * excessively into the page allocator
>> */
>> if (migratetype >= MIGRATE_PCPTYPES) {
>> - if (unlikely(is_migrate_isolate(migratetype))) {
>> + if (unlikely(is_migrate_isolate(migratetype) ||
>> + migratetype == MIGRATE_HIGHATOMIC)) {
>> free_one_page(zone, page, pfn, 0, migratetype);
>> goto out;
>> }
>
> In any case your patch highlighted that this code could be imho
> optimized like below.
>
> if (unlikely(migratetype >= MIGRATE_PCPTYPES))
> if (is_migrate_cma(migratetype)) {
> migratetype = MIGRATE_MOVABLE;
> } else {
> free_one_page(zone, page, pfn, 0, migratetype);
> goto out;
> }
> }
>
> That's less branches than your patch, and even less than originally if
> CMA is not enabled (or with ZONE_CMA).

Yeah, this looks better.

\
 
 \ /
  Last update: 2016-06-19 05:21    [W:0.064 / U:0.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site