: [ML] It is possible to handle these cases in VM code, by
: trapping on any access to the partial page, and allowing only those
: accesses which are withing the originally requested range. Performance
: would suck without end, though.
:
:Well it would only suck for access to that page
On Mon, 28 Jun 1999, Matthew Dillon wrote:
: 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
On Mon, 28 Jun 1999 12:54:12 -0700 (PDT)
Matthew Dillon [EMAIL PROTECTED] wrote:
mmap bypasses the vnode. What you propose will not work because even if
the VM object is process-specific, the pages underlying the VM object are
not. If several processes are mmap()ing
:Well, if you make a VM object map-entry-specific (not just "process-specific";
:a single process may have multiple mappings of a file!), then the pages
:*can't* be shared, because pages are owned by the objects. The only reason
:you can share pages is because multiple map entries may reference
:
:By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ()
:and VOP_WRITE() just as read() and write() system call.
Yes, but what they are doing is mapping the VMIO cache pages into the
buffer, so the VOP_READ/VOP_WRITE essentially operates directly on the
VMIO
:
:All these situations seem to me are not handled by FreeBSD mmap()
code. I
:hope I am wrong. I also wonder why we can not add some information to
the
No machine's mmap() code handles these situations. It is a side
effect
of the way MMU's work and the way mmap() was defined -
On 28-Jun-99 Ladavac Marino wrote:
[ML] It is possible to handle these cases in VM code, by
trapping on any access to the partial page, and allowing only those
accesses which are withing the originally requested range. Performance
would suck without end, though.
Well it would only
: [ML] It is possible to handle these cases in VM code, by
: trapping on any access to the partial page, and allowing only those
: accesses which are withing the originally requested range. Performance
: would suck without end, though.
:
:Well it would only suck for access to that page
: Otherwise they wouldn't bother to use mmap and instead would use read()
: and write() :-)
:
:Hmm.. why (unless you forced mmap to use the address you gave it) would it not
:choose the start address to be on a page boundary?
:
:---
:Daniel O'Connor software and network engineer
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
: 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
On Mon, 28 Jun 1999, Matthew Dillon wrote:
: 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
On Mon, 28 Jun 1999 12:54:12 -0700 (PDT)
Matthew Dillon dil...@apollo.backplane.com wrote:
mmap bypasses the vnode. What you propose will not work because even if
the VM object is process-specific, the pages underlying the VM object are
not. If several processes are
:Well, if you make a VM object map-entry-specific (not just process-specific;
:a single process may have multiple mappings of a file!), then the pages
:*can't* be shared, because pages are owned by the objects. The only reason
:you can share pages is because multiple map entries may reference the
:
:By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ()
:and VOP_WRITE() just as read() and write() system call.
Yes, but what they are doing is mapping the VMIO cache pages into the
buffer, so the VOP_READ/VOP_WRITE essentially operates directly on the
VMIO
This is how mmap() is supposed to work. mmap() may return an area larger
then the one you specified due to page-alignment considerations. It is
not legal for you to write in an area which is outside the range you
specified, but there is no way for the machine to enforce this except
16 matches
Mail list logo
