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] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 14 Jul 2014 15:28:52 +0900
From:	Joonsoo Kim <>
To:	Vlastimil Babka <>
Cc:	Andrew Morton <>,
	"Kirill A. Shutemov" <>,
	Rik van Riel <>,
	Peter Zijlstra <>,
	Mel Gorman <>,
	Johannes Weiner <>,
	Minchan Kim <>,
	Yasuaki Ishimatsu <>,
	Zhang Yanfei <>,
	"Srivatsa S. Bhat" <>,
	Tang Chen <>,
	Naoya Horiguchi <>,
	Bartlomiej Zolnierkiewicz <>,
	Wen Congyang <>,
	Marek Szyprowski <>,
	Michal Nazarewicz <>,
	Laura Abbott <>,
	Heesub Shin <>,
	"Aneesh Kumar K.V" <>,
	Ritesh Harjani <>,, Gioh Kim <>,,
Subject: Re: [PATCH 05/10] mm/page_alloc: optimize and unify pageblock
 migratetype check in free path

On Mon, Jul 07, 2014 at 05:50:09PM +0200, Vlastimil Babka wrote:
> On 07/04/2014 09:57 AM, Joonsoo Kim wrote:
> >Currently, when we free the page from pcp list to buddy, we check
> >pageblock of the page in order to isolate the page on isolated
> >pageblock. Although this could rarely happen and to check migratetype of
> >pageblock is somewhat expensive, we check it on free fast path. I think
> >that this is undesirable. To prevent this situation, I introduce new
> >variable, nr_isolate_pageblock on struct zone and use it to determine
> >if we should check pageblock migratetype. Isolation on pageblock rarely
> >happens so we can mostly avoid this pageblock migratetype check.
> Better, but still there's a zone flag check and maintenance. So if
> it could be avoided, it would be better.
> >Additionally, unify freepage counting code, because it can be done in
> >common part, __free_one_page(). This unifying provides extra guarantee
> >that the page on isolate pageblock don't go into non-isolate buddy list.
> >This is similar situation describing in previous patch so refer it
> >if you need more explanation.
> You should make it clearer that you are solving misplacement of the
> type "page should be placed on isolated freelist but it's not"
> through free_one_page(), which was solved only for
> free_pcppages_bulk() in patch 03/10. Mentioning patch 04/10 here,
> which solves the opposite problem "page shouldn't be placed on
> isolated freelist, but it is", only confuses the situation. Also
> this patch undoes everything of 04/10 and moves it elsewhere, so
> that would make it harder to git blame etc. I would reorder 04 and
> 05.

Okay. I will clarify what I am solving in commit description and
reorder patches appropriately.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists