Re: AMAP_SHARED (was Re: XIP)

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

On Tue, Nov 02, 2010 at 03:09:51PM +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?

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.

> 
> 
> .mrg.

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635