Re: AMAP_SHARED (was Re: XIP)

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Tue, Nov 02, 2010 at 03:47:55PM +1100, matthew green wrote:
> 
> > > > > > - For highly tuned, XIP'ed systems, programs should be designed to
> > > > > >   avoid .data, because they're COW'ed to page cache sooner or later.
> > > > > 
> > > > > why is this a problem?
> > > > > 
> > > > > if the data is needed, and it will be written to, then these pages
> > > > > will be allocated (COW'd) eventually, and the same space will be used.
> > > > 
> > > > Not a problem, as in it works.
> > > > 
> > > > As already explained, we allocate PV for XIP segments, only for
> > > > vnode-backed AMAP_SHARED == shared .data.  Careful users may design
> > > > the whole system to not allocate PV at all, by giving up that
> > > > feature.  To help user's design decision, I stated the obvious -
> > > > .data is XIP-unfriendly.
> > > 
> > > but why is it unfriendly?  i don't see why.  there's going to
> > > be the same number of pages allocated for writeable data in
> > > both cases, so the same amount of resources will be consumed.
> > 
> > What do you mean by "both cases" here?
> 
> i mean moving stuff from .data to elsewhere, compared to the
> normal method.
> 
> > If a small program has both .data and .bss, and if .data is small,
> > I'd use .rodata and copy it to .bss explicitly, so that resulting
> > process allocates only .bss anon instead .data + .bss.
> 
> why is this useful?  what's the saving?  maybe one page if
> roundup(data + bss) is smaller than roundup(data) +
> roundup(bss).
> 
> my point is that if a program needs data, whether it is from
> the .data or .bss, the same amount of resources will be
> consumed when pages are written to (or not.)  (possibly there
> is a one-page saving...)

You're right.

One page saving is a saving too.

> 
> 
> .mrg.