lkml.org 
[lkml]   [2004]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:1.181 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site