linux-kernel - Re: [PATCH] mm: reset migratetype if the range spans two pageblocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5620E6BF.7090602@suse.cz>
Date:	Fri, 16 Oct 2015 13:59:59 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Xishi Qiu <qiuxishi@...wei.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>, mhocko@...e.com,
	js1304@...il.com, Johannes Weiner <hannes@...xchg.org>,
	alexander.h.duyck@...hat.com, zhongjiang@...wei.com
Cc:	Linux MM <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: reset migratetype if the range spans two pageblocks

On 10/16/2015 12:06 PM, Xishi Qiu wrote:
> __rmqueue_fallback() will change the migratetype of pageblock,
> so it is possible that two continuous pageblocks have different
> migratetypes.
>
> When freeing all pages of the two blocks, they will be merged
> to 4M, and added to the buddy list which the migratetype is the
> first pageblock's.
>
> If later alloc some pages and split the 4M, the second pageblock
> will be added to the buddy list, and the migratetype is the first
> pageblock's, so it is different from the its pageblock's.
>
> That means the page in buddy list's migratetype is different from
> the page in pageblock's migratetype. This will make confusion.

So what will be the bad effects of this confusion? There are many 
situations where a free page (of any size) will be on different list 
than the pageblock's migratetype.

In case of full free pageblock, it IIRC doesn't really matter on which 
freelist it is, as the fallback scenarios for all migratetypes are 
trivial and non-fragmenting (just grab the whole pageblock, which means 
the migratetype is updated).

Maybe compaction will get it wrong when deciding which pageblocks are 
suitable for scanning, but that's not critical.

> However,if we change the hotpath, it will be performance degradation,
> so any better ideas?

I don't see immediately a way to fix that outside of hotpath, and don't 
see the reasons being strong enough to fix it in the hotpath.

>
> Signed-off-by: Xishi Qiu <qiuxishi@...wei.com>
> ---
>   mm/page_alloc.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 48aaf7b..5c91348 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -726,6 +726,9 @@ static inline void __free_one_page(struct page *page,
>   	list_add(&page->lru, &zone->free_area[order].free_list[migratetype]);
>   out:
>   	zone->free_area[order].nr_free++;
> +	/* If the range spans two pageblocks, reset the migratetype. */
> +	if (order > pageblock_order)
> +		change_pageblock_range(page, order, migratetype);
>   }
>
>   static inline int free_pages_check(struct page *page)
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/