linux-kernel - Re: [PATCH v2 0/6] Introduce ZONE

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]

Date:	Tue, 3 May 2016 10:29:34 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Vlastimil Babka <vbabka@...e.cz>
Cc:	Mel Gorman <mgorman@...hsingularity.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Laura Abbott <lauraa@...eaurora.org>,
	Minchan Kim <minchan@...nel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/6] Introduce ZONE_CMA

On Mon, May 02, 2016 at 09:49:47AM +0200, Vlastimil Babka wrote:
> On 05/02/2016 08:14 AM, Joonsoo Kim wrote:
> >>>> >Although it's separate issue, I should mentioned one thing. Related to
> >>>> >I/O pinning issue, ZONE_CMA don't get blockdev allocation request so
> >>>> >I/O pinning problem is much reduced.
> >>>> >
> >>>
> >>>This is not super-clear from the patch. blockdev is using GFP_USER so it
> >>>already should not be classed as MOVABLE. I could easily be looking in
> >>>the wrong place or missed which allocation path sets GFP_MOVABLE.
> >Okay. Please see sb_bread(), sb_getblk(), __getblk() and __bread() in
> >include/linux/buffer_head.h. These are main functions used by blockdev
> >and they uses GFP_MOVABLE. To fix permanent allocation case which is
> >used by mount and cannot be released until umount, Gioh introduces
> >sb_bread_unmovable() but there are many remaining issues that prevent
> >migration at the moment and avoid blockdev allocation from CMA area is
> >preferable approach.
> 
> Hm Patch 3/6 describes the lack of blockdev allocations mostly as a
> limitation, although it does mention the possible advantages later.

Because what this patch try to do isn't an optimization. It would be
best to maintain previous behaviour as much as possible but it
doesn't. Therfore, I mentioned it as side-effect of this patch
although it seems to be a good thing to me.

> Anyway, this doesn't have to be specific to ZONE_CMA, right? You
> could just change ALLOC_CMA handling to consider
> GFP_HIGHUSER_MOVABLE instead of just __GFP_MOVABLE. For ZONE_CMA it
> might be inevitable as you describe, but it's already possible to do
> that now, if the advantages are larger than the disadvantages.

I think that it's not easy. Even if we just allow freepages on CMA area
when GFP_HIGHUSER_MOVABLE allocation request comes, compaction could move
__GFP_MOVABLE pages to freepages on CMA pageblock. Allocated page has no
knowledge about requested gfp and compaction just assume that
migration within a single zone is safe. So, compaction would migrate
__GFP_MOVABLE blockdev pages on ordinary pageblock to the page on CMA
pageblock and we can't easily prevent it. I guess it would be marginal
amount but I'm not sure whether it causes some other problems or not.

Thanks.