>
> Because we can't realign the data in the pages without doing a buffer
> copy. To force mmap() to align the data to the start of the page requires
> it to allocate memory and copy the in-core disk cache to the new memory.
>
> This is extremely wasteful of cpu and memory. The current UNIX mmap
> implementation is able to simply map the existing in-core disk cache
> directly to the process - no buffer copying is required at all, and
> it is extremely memory efficient.
I guess you are talking about VMIO buffers where the pages are found and
registered into the buffer header during allocbuf(). When we do I/O on
VMIO buffers using conventional system call method, we specify UIO_NOCOPY
to instruct the uiomove() do not perform data copy.
> Programmers who use mmap() expect it to be as close to optimal as
> possible.
I write a program to test the mmap() today. It turns out that a user can
modify the part of the mmapped area that is within the system returned
area but not part of the user-specified area.
As I understand it, there are two access paths to a file: conventional I/O
through read/write systems calls and memory-mapped I/O. Both of them
converge at the vnode read and write routine (VOP_READ() and VOP_WRITE()).
This should give us the opportunity to guard against illegal memory-mapped
I/O writes made by the user.
Maybe we can add some fields in the vm_object to record the real or
user-specifed area which can be passed to the vnode read and write
routine. In the vnode I/O routine, we should be able to limit the write to
only the orginal part of the area specified by the user. This practice
should not incur any performance loss.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
