![]() | |||||||||||||
Messages in this thread |
On Tue, Mar 30, 2004 at 06:27:18AM +0100, Hugh Dickins wrote: > On Tue, 30 Mar 2004, Andrea Arcangeli wrote:> > On Mon, Mar 29, 2004 at 08:44:25PM +0100, Hugh Dickins wrote: > > > > > So I assume that what's there is needed, and the example below > > > does looks plausible enough: add page, fill it, protect it, ...> > > > this will work perfect, absolutely perfect. You didn't read my code well > > enough.> > Sure, and I most certainly haven't read your future code well enough. > Your present implementation, one vma per page (in that real case where > vmas are properly merged by mainline or anonmm), is far from perfect. > > anon_vma has surprised me more than once by working smoothly just > where I thought it must go wrong. Please do surprise me again: > write that code and post the patch which resolves this doubt. I will, it just wasn't high prio enough at this time (I mean, I still have pending some prio-tree bit to fixup with the xfs, that was higher prio since it impacts functionality, and the mremap race may also be higher prio). My point is that merging in your program will work fine, this is what matters to me, it doesn't right now because I didn't fixup the merging code yet, but there's nothing that will prevent your program to use just 1 single vma for the whole thing (after I fixup the merging code ;). The bonus is that after I fixup the merging, it'll use 1 vma even for the file mappings, not just for anonymous memory, something that is not true with anonmm (and the complexity of doing file merging or anon-vma merging is the same, so I will do both at the same cost). - 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/ | ||||||||||||
| Last update: 2005-03-22 13:02 [from the cache] ©2003-2008 | |||||||||||||