Thanks for the clarification. Pending the successful outcome of the project you mention, your use of the phrase "private anonymous memory" intrigues me and thus I'll ask about an idea I had to finess this issue. Lets say I have a process whose sole task is to export a memory region. It would set the heap page size to 4m, allocate a suitably sized and aligned block of autonymous memory, possibly by mapping /dev/zero or whatever. Then it could read the contents of these files that our process mmap today. Then,it could change the permissions and attributes of the region to shared and then publish this address by some means. If I understand things, some other process could open /proc/<pid>/as and mmap that offset, yielding shared large pages. Any obvious hole in that thinking?
> -----Original Message----- > From: Dave Marquardt [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 05, 2005 8:25 AM > To: David McDaniel (damcdani) > Cc: perf-discuss@opensolaris.org > Subject: Re: [perf-discuss] General question re large pages OOB > > "David" == David McDaniel <[EMAIL PROTECTED]> writes: > > David> Hi all. I've heard of the effort to broaden the use of large > David> pages to cover things besides anonymous memory. The > application I > David> workon has the properties of (1) "sharing" gigabytes of memory > David> between process by way of memory mapped files and alas > David> (2) being dragged down by dtlb and dtsb miss rates. So > I wanted > David> to know if this effort would enable us to map these files into > David> large pages to improve the situation. Thanks -d > > Sorry, no, LPOOB covers heap, stack and private anonymous memory. > However, memcntl()'s MC_HAT_ADVISE interface has been > extended (by another large page project, MPSS for Vnodes) to > work with regular files. > -- > Dave Marquardt > Sun Microsystems, Inc. > Austin, TX > +1 512 401-1077 > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
