On Wed, Oct 05, 2005 at 12:26:37PM -0500, Dave Marquardt wrote: > "David" == David McDaniel <(damcdani)" <[EMAIL PROTECTED]>> writes: > > David> Thanks for the clarification. Pending the successful outcome of the > David> project you mention, your use of the phrase "private anonymous memory" > David> intrigues me and thus I'll ask about an idea I had to finess this > issue. > > Hmm, I'm not sure what the right term is. I'm referring to memory > created with mmap() with the (MAP_ANON|MAP_PRIVATE) flags. > > David> Lets say I have a process whose sole task is to export a memory > David> region. It would set the heap page size to 4m, allocate a suitably > sized > David> and aligned block of autonymous memory, possibly by mapping /dev/zero > or > David> whatever. Then it could read the contents of these files that our > David> process mmap today. Then,it could change the permissions and attributes > David> of the region to shared and then publish this address by some means. If > David> I understand things, some other process could open /proc/<pid>/as and > David> mmap that offset, yielding shared large pages. > > If you create a heap large enough (typically 6MB on a SPARC-based > system), LPOOB will set the heap page size to 4MB, but if you wanted > to make sure, you could use memcntl(). > > If you map /dev/zero, that's going to a separate segment, not the > heap. I'm not what happens if you try to mmap() /dev/zero into the > heap, but I suspect it fails. > > What you're doing sounds like (intimate) shared memory to me. You > somehow have to read the data into that memory. > > David> Any obvious hole in that thinking? > > Well, proc(4) says you can do stuff like that, so I guess it would work.
You cannot mmap(2) /proc/whatever/as; only read/write/pread/pwrite work. You should probably look at Sys V shared memory. Cheers, - jonathan > >> -----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 > >> > > > > -- > Dave Marquardt > Sun Microsystems, Inc. > Austin, TX > +1 512 401-1077 > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org -- Jonathan Adams, Solaris Kernel Development _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
