Messages in this thread | | | Date | Thu, 15 Apr 2004 14:45:21 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: Benchmarking objrmap under memory pressure |
| |
On Thu, 15 Apr 2004, Andrea Arcangeli wrote: > > yes, that's a major benefit, doing vma merging with file mappings is a > lot more important than for anonymous ram, most people only uses > mprotect to switch the write bit on the vma before/after using some > MAP_SHARED segment, if a bug accours while they don't use the mapping > they won't risk to corrupt the data. That's a very common behaviour for > big apps and it has never been possible to merge until now in anon-vma.
I like file vma merging, but I am puzzled why we (you) bothered to implement anon vma merging before and not file vma merging, if the file vma merging is so much more important. I suppose it's something you learnt later, or the apps evolved.
> But this is pretty orthgonal with the anon-vma vs anonmm comparison, if > you're ok to deal with the anon-vma complexity you can merge this bit on > top of anonmm too, the compexity of doing anon-vma merging is the same > one of doing the inode-vma merging.
Indeed. If anonmm does live on, I would want to add the file vma merging; but when things (mpol, prio_tree, i_shared locking) have settled down rather than now - we've lived without it for some years, can live without it for a few weeks more.
Hugh
- 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/
| |