On 09/10/2014 09:28 PM, Dave Hansen wrote: <> > > OK, so what happens when a page is truncated out of a file and this > "last" block reference is dropped while a get_user_pages() still has a > reference? > I have a very simple plan for this scenario, as I said, hang these pages with ref!=1 on a garbage list, and one of the clear threads can scan them periodically and release them. I have this test in place, currently what I do is just drop the block and let it leak (that is, not be used any more) until a next mount where this will be returned to free store. Yes stupid I know. But I have a big fat message when this happens and I have not been able to reproduce it. So I'm still waiting for this test case, I guess DAX protects me. <> > From my perspective, DAX is complicated, but it is necessary because we > don't have a 'struct page'. You're saying that even if we pay the cost > of a 'struct page' for the memory, we still don't get the benefit of > having it like getting rid of this DAX stuff? > No DAX is still necessary because we map storage directly to app space, and we still need it persistent. That is we can-not/need-not use an in-ram radix tree but directly use on-storage btrees. Regular VFS has this 2 tiers model, volatile-ram over persistent store. DAX is an alternative VFS model where you have a single tier. the name implies "Direct Access". So this is nothing to do with page cost or "benefit". DAX is about a new VFS model for new storage technologies. And please be noted, the complexity you are talking about is just a learning curve, on the developers side. Not a technological one. Actually if you compare the two models, lets call them VFS-2t and VFS-1t, then you see that DAX is an order of a magnitude simpler then the old model. Life is hard and we do need the two models all at the same time, to support all these different devices. So yes the complexity is added with the added choice. But please do not confuse, DAX is not the complicated part. Having a Choice is. > Also, about not having a zone for these pages. Do you intend to support > 32-bit systems? If so, I believe you will require the kmap() family of > functions to map the pages in order to copy data in and out. kmap() > currently requires knowing the zone of the page. No!!! This is strictly 64 bit. A 32bit system is able to have at maximum 3Gb of low-ram + storage. DAX implies always mapped. That is, no re-mapping. So this rules out more then a G of storage. Since that is a joke then No! 32bit is out. You need to understand current HW std talks about DDR4 and there are DDR3 samples flouting around. So this is strictly 64bit, even on phones. 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
