On 10/10/2014 05:24 PM, Matthew Wilcox wrote: <> > > I'm assuming that we come up with *some* way to solve the missing struct > page problem. Whether it's restructuring splice, O_DIRECT and RDMA to do > without struct pages, That makes no sense to me, where will it end? You are doubling the size of the code to have two paths, and there will always be a subsystem you did not touch and is missing support. And why? page was already invented to do exactly what you want, track state of a PFN. > whether it's dynamically allocating struct pages, I have tried this. It does not work. The PFN <-> page mapping is directly calculated from the phisical/virtual addresses. Through the use of the section object. struct page is actually just a part of a bigger "section" object. You do not allocate an individual page-struct. You need to allocate a memory "section" > whether it's statically allocating struct pages, The best I came up with was "hotplug" allocation. It is rather static, but hot plugable. Please inspect my patches. This came out very simple, the minimum code possible that gives you all the above support, without need to change any of these subsystems, and plugs just nicely into all the other subsystems you have not mentioned. > whether it's coming up > with some other data structure that takes the place of struct page for > DAX ... Again. Why reinvent the wheel when the old one works perfectly and does everything you want, including the most important aspect. Not adding any new infrastructure, and/or modifying any code. So why even think about it? > doesn't matter for this part of the conversation. > I agree, this does not solve the reference problem, in this case DAX will need an new entry into the FS to communicate delayed free-block. But as Jan pointed out this is not against current FS structure. I think lots of current DAX problems and performance short comings can be solved very nicely if we assume we have struct-page for pmem. For example the use of the page-lock instead of the i_mutex we take today. Thanks Boaz -- 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
