Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754794Ab3HMHFF (ORCPT ); Tue, 13 Aug 2013 03:05:05 -0400 Received: from lgeamrelo02.lge.com ([156.147.1.126]:44209 "EHLO LGEAMRELO02.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998Ab3HMHFC (ORCPT ); Tue, 13 Aug 2013 03:05:02 -0400 X-AuditID: 9c93017e-b7c76ae000003897-c9-5209da9b66bb From: Minchan Kim To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, k.kozlowski@samsung.com, Seth Jennings , Mel Gorman , guz.fnst@cn.fujitsu.com, Benjamin LaHaise , Dave Hansen , lliubbo@gmail.com, aquini@redhat.com, Rik van Riel , Minchan Kim Subject: [RFC 0/3] Pin page control subsystem Date: Tue, 13 Aug 2013 16:04:59 +0900 Message-Id: <1376377502-28207-1-git-send-email-minchan@kernel.org> X-Mailer: git-send-email 1.7.9.5 X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3089 Lines: 67 !! NOTICE !! It's totally untested patchset so please AVOID real testing. I'd like to show just concept and want to discuss it on very early stage. (so there isn't enough description but I guess code is very simple so not a big problem to understand the intention). This patchset is for solving *kernel* pinpage migration problem more general. Now, zswap, zram and z* family, not sure upcoming what solution are using memory don't live in harmony with VM. (I don't remember ballon compaction but we might be able to unify ballon compaction with this.) VM sometime want to migrate and/or reclaim pages for CMA, memory-hotplug, THP and so on but at the moment, it could handle only userspace pages so if above example subsystem have pinned a some page in a range VM want to migrate, migration is failed so above exmaple couldn't work well. This patchset is for basic facility for the role. patch 1 introduces a new page flags and patch 2 introduce pinpage control subsystem. So, subsystems want to control pinpage should implement own pinpage_xxx functions because each subsystem would have other character so what kinds of data structure for managing pinpage information depends on them. Otherwise, they can use general functions defined in pinpage subsystem. patch 3 hacks migration.c so that migration is aware of pinpage now and migrate them with pinpage subsystem. It exposes new rule that users of pinpage control subsystem shouldn't use struct page->flags and struct page->lru field freely because lru field is used for migration.c and flags field is used for lock_page in pinpage control subsystem. I think it's not a big problem because subsystem can use other fields of the page descriptor, instead. This patch's limitation is that it couldn't apply user space pages although I'd REALLY REALLY like to unify them. IOW, it couldn't handle long pin page by get_user_pages. Basic hurdle is that how to handle nesting cases caused by that several subsystem pin on same page with GUP but they could have different migrate methods. It could add rather complexity and overhead but I'm not sure it's worth because proved culprit until now is AIO ring pages and Gu and Benjamin have approached it with another way so I'd like to hear their opinions. Minchan Kim (3): mm: Introduce new page flag pinpage control subsystem mm: migrate pinned page include/linux/page-flags.h | 2 + include/linux/pinpage.h | 39 +++++++++++++ mm/Makefile | 2 +- mm/compaction.c | 26 ++++++++- mm/migrate.c | 58 ++++++++++++++++--- mm/page_alloc.c | 1 + mm/pinpage.c | 134 ++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 252 insertions(+), 10 deletions(-) create mode 100644 include/linux/pinpage.h create mode 100644 mm/pinpage.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/