Hi Rik, Added Mel, Andrea and Peterz to CC as interested parties. There are probably others, please just jump in. On 05/14/2015 05:59 AM, Rik van Riel wrote: > On 05/14/2015 04:26 AM, Daniel Phillips wrote: >> Hi Rik, >> >> Our linux-tux3 tree currently currently carries this 652 line diff >> against core, to make Tux3 work. This is mainly by Hirofumi, except >> the fs-writeback.c hook, which is by me. The main part you may be >> interested in is rmap.c, which addresses the issues raised at the >> 2013 Linux Storage Filesystem and MM Summit 2015 in San Francisco.[1] >> >> LSFMM: Page forking >> http://lwn.net/Articles/548091/ >> >> This is just a FYI. An upcoming Tux3 report will be a tour of the page >> forking design and implementation. For now, this is just to give a >> general sense of what we have done. We heard there are concerns about >> how ptrace will work. I really am not familiar with the issue, could >> you please explain what you were thinking of there? > > The issue is that things like ptrace, AIO, infiniband > RDMA, and other direct memory access subsystems can take > a reference to page A, which Tux3 clones into a new page B > when the process writes it. > > However, while the process now points at page B, ptrace, > AIO, infiniband, etc will still be pointing at page A. > > This causes the process and the other subsystem to each > look at a different page, instead of at shared state, > causing ptrace to do nothing, AIO and RDMA data to be > invisible (or corrupted), etc... Is this a bit like page migration? Regards, Daniel -- 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
