Re: improvements to mmap?
Re: improvements to mmap?
- Subject: Re: improvements to mmap?
- From: Jens Alfke <email@hidden>
- Date: Fri, 5 Feb 2010 09:21:00 -0800
On Feb 5, 2010, at 9:02 AM, Andrew Gallatin wrote:
> We did something like this in a research group I worked for 12 years
> ago. See MMB in section 4.2.1 of "Cheating the I/O Bottleneck: Network Storage with Trapeze/Myrinet" (http://www.cs.duke.edu/ari/publications/cheating.pdf)
Interesting stuff! I've copied the relevant bits below:
> MMB uses the mmap system call in a block-oriented fashion, repeatedly mapping N regions of virtual memory of size B to different ranges of offsets in the file. Our MMB experiments use B = 256K and N = 2 (double buffering). Like whole-file mmap, MMB is a zero-copy file access scheme; it incurs slightly higher system call overhead than mmap, but our results show that this is insignificant with sufficiently low N and sufficiently large B, and is overshadowed by other benefits. Like stream, MMB allows the application to explicitly specify its accesses to the kernel. This information can be exploited by the kernel to improve performance for applications that use MMB. Moreover, MMB is an asynchronous interface, allowing the application to specify accesses early in order to overlap file access with computation.
>
> We have modified our Digital Unix kernels to detect MMB accesses and respond with the following policies:
> • When an MMB mmap call is issued, the kernel immediately initiates an asynchronous prefetch of all pages in the newly mapped region, superseding the usual read-ahead policy.
> • The memory frames that previously backed the remapped region are released, discarding the mapped-over file blocks from the local file cache, and pushing them to the network if necessary. This allows the application to control the local cache replacement policy by selecting the region to remap, and reduces the overhead of the paging daemon and LRU eviction code.
> • We have extended the mmap interface with a MAP OVERWRITE flag that allows the application to specify that the mapped file region will be overwritten without reading it; in this case, the kernel may simply leave the existing frames mapped, but change their identity in the file cache. The new flag fixes an inherent flaw in mmap: when a process references a page in a mapped region, the kernel does not know if the process will read from that page, so it must initialize the frame by zeroing it or reading it from the file. Our approach will expose corrupt data to a process that mistakenly reads from a region mapped with MAP OVERWRITE, but it will never violate security by leaking data belonging to another process.
>
> We emphasize that with the exception of the new flag, these policies do not change the semantics of the standard mmap interface, but only its performance. We leave a detailed study of the MMB interface and its usage to future work.
—Jens
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden