Date: Fri, 4 Dec 1998 12:03:18 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Kevin Day <toasty@home.dragondata.com>, hackers@FreeBSD.ORG Subject: Re: Nonblocking page fetching Message-ID: <199812042003.MAA17061@apollo.backplane.com> References: <199812041431.IAA27124@home.dragondata.com> <199812041934.LAA16719@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
::What would be very nice is a syscall that could tell the vm system that a
::page will be needed shortly, so bring it in as soon as possible. Sort of
::like madvising with WILL_NEED, but a much stronger hint.
:
: The facility already exists in the system. In fact, it even exists in
: -stable.
:
: mmap() the region as per normal.
:
: madvise() the region to be MADV_WILLNEED
: madvise() the region to be MADV_SEQUENTIAL
Oh, quick adjustment: don't do the MADV_WILLNEED. The reason you
do not want to do it is because if you do the kernel will instantiate
the pte's for any pages related to the file that are already in the
buffer cache, which can actually interfere with the read-ahead mechanism
outlined below. By starting with a clean page-table slate, the faults
occur where they are supposed to occur.
: The kernel will read-ahead. Now, it will not read-ahead quickly enough
: to avoid blocking, but you may be able to tune the kernel specifically
: to handle your situation. Take a look at the code in vm/vm_fault.c,
: around line 351. Also look at the VM_FAULT_READ_AHEAD and
: VM_FAULT_READ_BEHIND defines.
:
: The key to making this work in a full-streaming application is to
: issue I/O for N pages ahead but to not fault-in one page in the center
: of that group. You then take a page fault when you hit that page, but
: since it is in the buffer cache it doesn't block and the kernel takes
: the opportunity to issue read-aheads for the next N pages (of which N/2
: already probably in the buffer cache). If you make N big enough, you
: are all set.
:
: Note, however, that disk I/O bandwidth is much less then memory bandwidth
: and probably much less then video-write bandwidth. If you have limited
: memory to buffer the data, you *will* block at some point.
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812042003.MAA17061>