Hi Minchan, On 02/05/2013 08:58 AM, Minchan Kim wrote: > Hello, > > On Mon, Feb 04, 2013 at 06:04:06PM +0800, Lin Feng wrote: >> Currently get_user_pages() always tries to allocate pages from movable zone, >> as discussed in thread https://lkml.org/lkml/2012/11/29/69, in some case >> users >> of get_user_pages() is easy to pin user pages for a long time(for now we >> found >> that pages pinned as aio ring pages is such case), which is fatal for memory >> hotplug/remove framework. >> >> So the 1st patch introduces a new library function called >> get_user_pages_non_movable() to pin pages only from zone non-movable in >> memory. >> It's a wrapper of get_user_pages() but it makes sure that all pages come from >> non-movable zone via additional page migration. >> >> The 2nd patch gets around the aio ring pages can't be migrated bug caused by >> get_user_pages() via using the new function. It only works when configed with >> CONFIG_MEMORY_HOTREMOVE, otherwise it uses the old version of >> get_user_pages(). > > CMA has same issue but the problem is the driver developers or any subsystem > using GUP can't know their pages is in CMA area or not in advance. > So all of client of GUP should use GUP_NM to work them with > CMA/MEMORY_HOTPLUG well? > Even some driver module in embedded side doesn't open their source code. Yes, it somehow depends on the users of GUP. In MEMORY_HOTPLUG case, as for most users of GUP, they will release the pinned pages immediately and to such users they should get a good performance, using the old style interface is a smart way. And we had better just deal with the cases we have to by using the new interface. > > I would like to make GUP smart so it allocates a page from > non-movable/non-cma area > when memory-hotplug/cma is enabled(CONFIG_MIGRATE_ISOLATE). Yeb. it might > hurt GUP > performance but it is just trade-off for using CMA/memory-hotplug, IMHO. :( As I debuged the get_user_pages(), I found that some pages is already there and may be allocated before we call get_user_pages(). __get_user_pages() have following logic to handle such case. 1786 while (!(page = follow_page(vma, start, foll_flags))) { 1787 int ret; To such case an additional alloc-flag or such doesn't work, it's difficult to keep GUP as smart as we want :( , so I worked out the migration approach to get around and avoid messing up the current code :)
thanks, linfeng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
