Messages in this thread | | | Date | Sat, 3 Apr 2004 14:27:25 +0100 | From | Jamie Lokier <> | Subject | Re: [PATCH] cowlinks v2 |
| |
Pavel Machek wrote: > > > > Here's a tricky situation: > > > > > > > > 1. A file is cowlinked. Then each cowlink is mmap()'d, one per process. > > > > > > > > 2. At this point both mappings share the same pages in RAM. > > > > > > > > 3. Then one of the cowlinks is written to... > > > > > > Using mmap with PROT_WRITE on a cowlink must preemptively > > > break the link. > > > > I forget to mention, they are PROT_READ shared mappings. > > I'm not mm guru, but... with rmap, we should be able to find all the > users of that shared memory, and unmap their pages, right?
Yes. I bring it up only because it's tricky, and the simple cowlink implementations so far don't deal with it.
A page can only exist in one address_space. So if pages are shared before the cow is broken, the address_space must be of the shared cowid object, not an individual address_space per cowlink. Afterwards, the copied pages are in the non-shared cowlink object's address_space.
> Until copy is done, we don't do anything, because write is not allowed > to progress until copy is done. When copy is done we should unmap all > the pages that still point to "old" copy, let write progress, and make > users fault in.
I agree.
(Ross suggested using COW pages. While technically possible, that would be pretty complicated to implemented as it implies pages shared among more than one address_space, and the facility for write() to break COW sharing in the page cache, and update page tables when that happens.)
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |