* Terry Lambert <[EMAIL PROTECTED]> [020625 13:08] wrote: > > > > > At what point does it eat KVA that is other than for the backing > > > > data structures? > > > > > > It eats address space, not RAM. And even if the mappings are not > > > active (which they usually are, because of LRU and processes > > > accessing them shared), the pages containing the page table entries > > > for each process are themselves not swappable; anything with a > > > large VSZ is going to eat 1/4k pages in KVA there, too. > > > > > > Ask yourself where a shared memory segment lives when it's not in > > > attached to one process address space, prior to you ipcrm'ing it. > > > It has to remain referenced so it isn't reclaimed. > > > > Yes, but not mapped into the kernel's address space right? right??? > > Not for OBJT_PHYS, it seems: > > * Note: PG_UNMANAGED (used by OBJT_PHYS) indicates that the page is > * not under PV management but otherwise should be treated as a > * normal page. Pages not under PV management cannot be paged out > * via the object/vm_page_t because there is no knowledge of their > * pte mappings, nor can they be removed from their objects via > * the object, and such pages are also not on any PQ queue. > > Looks like it just eats physical memory.
Which is still not mapped in kernel memory. > If you look at the commit message on version 1.48, you'll see that > without this option specified by the user, it eats KVA space, since > it eats KVM. The OBJT_PHYS was added specifically to support not > eating KVA space (by Peter, for Oracle, according to the comment). I don't need this lesson, I'm the one that fixed this option to work with multiple shared segments.... :) This is also the _default_ for how solaris manages sysv segments, although it would be nice if we could get the OBJT_PHYS stuff to use 4meg pages (unless someone already did that?)... Anyhow, I'm glad we corrected your misconception and we now have a more accurate understanding of how this system works. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
