linux-kernel - Re: [RFC PATCH v2 0/4] mm: reclaim zbud pages on migration and compaction

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: <520911C5.5060506@intel.com>
Date:	Mon, 12 Aug 2013 09:48:05 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Minchan Kim <minchan@...nel.org>
CC:	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	guz.fnst@...fujitsu.com, bcrl@...ck.org
Subject: Re: [RFC PATCH v2 0/4] mm: reclaim zbud pages on migration and compaction

On 08/11/2013 07:25 PM, Minchan Kim wrote:
> +int set_pinned_page(struct pin_page_owner *owner,
> +			struct page *page, void *private)
> +{
> +	struct pin_page_info *pinfo = kmalloc(sizeof(pinfo), GFP_KERNEL);
> +
> +	INIT_HLIST_NODE(&pinfo->hlist);
> +	pinfo->owner = owner;
> +
> +	pinfo->pfn = page_to_pfn(page);
> +	pinfo->private = private;
> +	
> +	spin_lock(&hash_lock);
> +	hash_add(pin_page_hash, &pinfo->hlist, pinfo->pfn);
> +	spin_unlock(&hash_lock);
> +
> +	SetPinnedPage(page);
> +	return 0;
> +};

I definitely agree that we're getting to the point where we need to look
at this more generically.  We've got at least four use-cases that have a
need for deterministically relocating memory:

1. CMA (many sub use cases)
2. Memory hot-remove
3. Memory power management
4. Runtime hugetlb-GB page allocations

Whatever we do, it _should_ be good enough to largely let us replace
PG_slab with this new bit.
--
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/