On Thu, May 14, 2015 at 05:06:39PM -0700, Daniel Phillips wrote: > 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? > No, it's not. -- Mel Gorman SUSE Labs -- 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
