Joe Bonasera wrote:
The x86 HAT (D)ISM code is tricky. Here's why: pagesize is 4K, a large page is 2Meg (usually). So a pagetable covers either an entire 512 4K pages aligned at 2M or 512 2M pages aligned at 1Gig. To share a page table, the (D)ISM segment has to be either a multiple of (512) 4K pages aligned to a 2Meg boundar or a multiple of 512 2Meg pages aligned to a 1Gig boundary. When those alignment / size restrictions aren't met, then we can't really share the pagetables. So when you attach to the (d)ISM segment, we copy the values needed for the mappings into process local pagetables - ie. not really shared.
Thanks for pointing out the alignment and size restrictions for (D)ISM segments. If you specify 0 for the address to shmat(2) and use a multiple of 2 meg or 1 gig for the size, should you get a segment that is properly aligned?
I suspect the minor fault stuff doesn't work right, because to unload the mappings you'd have to hat_unshare() in all processes that have the DISM mapped in order to migrate it.
Is hat_pageunload() sufficient? Jonathan _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
