On 05/07/2015 10:42 AM, Dan Williams wrote: > On Thu, May 7, 2015 at 10:36 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: >> * Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >> So is there anything fundamentally wrong about creating struct page >> backing at mmap() time (and making sure aliased mmaps share struct >> page arrays)? > > Something like "get_user_pages() triggers memory hotplug for > persistent memory", so they are actual real struct pages? Can we do > memory hotplug at that granularity? We've traditionally limited them to SECTION_SIZE granularity, which is 128MB IIRC. There are also assumptions in places that you can do page++ within a MAX_ORDER block if !CONFIG_HOLES_IN_ZONE. But, in all practicality, a lot of those places are in code like the buddy allocator. If your PTEs all have _PAGE_SPECIAL set and we're not ever expecting these fake 'struct page's to hit these code paths, it probably doesn't matter. You can probably get away with just allocating PAGE_SIZE worth of 'struct page' (which is 64) and mapping it in to vmemmap[]. The worst case is that you'll eat 1 page of space for each outstanding page of I/O. That's a lot better than 2MB of temporary 'struct page' space per page of I/O that it would take with a traditional hotplug operation. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
