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 > machvm.
This was a reply to: http://mail-index.netbsd.org/tech-kern/2010/10/26/msg009085.html > - MAP_INHERIT_SHARE, used to implement minherit(). > this is the one that is the most trouble, since it's what AMAP_SHARED > 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. > > > .mrg.