From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752218AbbCaLdz (ORCPT <rfc822;w@1wt.eu>);
	Tue, 31 Mar 2015 07:33:55 -0400
Received: from mailout4.w1.samsung.com ([210.118.77.14]:12348 "EHLO
	mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750907AbbCaLdx (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 31 Mar 2015 07:33:53 -0400
X-AuditID: cbfec7f5-b7fc86d0000066b7-60-551a861d3a29
Message-id: <551A861B.7020701@samsung.com>
Date: Tue, 31 Mar 2015 14:33:47 +0300
From: Andrey Ryabinin <a.ryabinin@samsung.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
 Thunderbird/31.5.0
MIME-version: 1.0
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Dave Kleikamp <shaggy@kernel.org>, Christoph Hellwig <hch@lst.de>,
        Sebastian Ott <sebott@linux.vnet.ibm.com>,
        Mikulas Patocka <mpatocka@redhat.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        LKML <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        jfs-discussion@lists.sourceforge.net
Subject: Re: [patch v2 4/4] mm, mempool: poison elements backed by page
 allocator
References: <alpine.DEB.2.10.1503241607240.21805@chino.kir.corp.google.com>
 <alpine.DEB.2.10.1503241609370.21805@chino.kir.corp.google.com>
 <CAPAsAGwipUr7NBWjQ_xjA0CfeiZ0NuYAg13M4jYmWVe4V8Jjmg@mail.gmail.com>
 <alpine.DEB.2.10.1503261542060.16259@chino.kir.corp.google.com>
In-reply-to: <alpine.DEB.2.10.1503261542060.16259@chino.kir.corp.google.com>
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsVy+t/xy7qybVKhBj+uqVrMWb+GzeL9sh5G
	i5WrjzJZXPzYymRxedccNot7a/6zWkzsuMpk0bZkI5PFqa7DjBa37/xgduDyWDNvDaPHgk2l
	HptWdbJ5bPo0id3jxIzfLB4PDm1m8di94DOTx+6bDWwe7/ddZfP4vEkugCuKyyYlNSezLLVI
	3y6BK+NPV23BIfaKReeXsDYw9rN1MXJySAiYSMxofcgMYYtJXLi3HijOxSEksJRR4t7j2SwQ
	TjOTxN/ZK1lBqngFtCS+9jxgArFZBFQlJlzsBIuzCehJ/Ju1Haibg0NUIELi9mVOiHJBiR+T
	77GA2CICGhJtM/6DLWAWeM8kcejAebCEsECwxNaH16CWTWOSaJ4whR1kEKeAj8Sx/ZwgJjPQ
	/PsXtUDKmQXkJTavecs8gVFgFpIVsxCqZiGpWsDIvIpRNLU0uaA4KT3XSK84Mbe4NC9dLzk/
	dxMjJF6+7mBceszqEKMAB6MSD29htlSoEGtiWXFl7iFGCQ5mJRFemUKgEG9KYmVValF+fFFp
	TmrxIUYmDk6pBsb64oDkzH2z43x8vszfqq+hbxgw+9qW5q5oOcUlhb/OL3hm78TDwGj7QPtA
	xLlriYk9JkdTFbbN4OXjTjJP8F4jP7Xu1+YahVPKLseMW3TVOXscLtbtOSASXL+F99IZxT6W
	NcGn7108onT8/Cq2ymZRydYL1yoT2R4J/3G40cqxQ/Wb7gqnC0osxRmJhlrMRcWJABg2UA51	AgAA
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/27/2015 01:50 AM, David Rientjes wrote:
> We don't have a need to set PAGE_EXT_DEBUG_POISON on these pages sitting 
> in the reserved pool, nor do we have a need to do kmap_atomic() since it's 
> already mapped and must be mapped to be on the reserved pool, which is 
> handled by mempool_free().
> 

Hmm.. I just realized that this statement might be wrong.
Why pages has to be mapped to be on reserved pool?
mempool could be used for highmem pages and there is no need to kmap()
until these pages will be used.

drbd (drivers/block/drbd) already uses mempool for highmem pages:

static int drbd_create_mempools(void)
{
....
	drbd_md_io_page_pool = mempool_create_page_pool(DRBD_MIN_POOL_PAGES, 0);
....
}



static void bm_page_io_async(struct drbd_bm_aio_ctx *ctx, int page_nr) __must_hold(local)
{
....
		page = mempool_alloc(drbd_md_io_page_pool, __GFP_HIGHMEM|__GFP_WAIT);
		copy_highpage(page, b->bm_pages[page_nr]);