[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: AMAP_SHARED (was Re: XIP)
On Tue, Nov 02, 2010 at 02:36:30PM +1100, matthew green wrote:
> > - AMAP_SHARED itself is a fine concept; it's used by shared memory.
> > sys/kern/sysv_shm.c:
> > 452 error = uvm_map(&vm->vm_map, &attach_va, size, uobj, 0,
> > 0,
> > 453 UVM_MAPFLAG(prot, prot, UVM_INH_SHARE,
> > UVM_ADV_RANDOM, flags));
> > (Note UVM_INH_SHARE == MAP_INHERIT_SHARE).
> > I guess MAP_INHERIT_SHARE was added because adding it was easy
> > after shared amap was implemented for shared memory?
> MAP_INHERIT_SHARE was originally MAP_INHERIT, and came from
This was a reply to:
> - MAP_INHERIT_SHARE, used to implement minherit().
> this is the one that is the most trouble, since it's what
> was invented for. however, it's also of least importance since
Even if MAP_INHERIT_SHARE preceded SYSV SHM, we need AMAP_SHARED anyway.
(I don't know if Mach had shared memory.)
> > - 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.
Main Index |
Thread Index |