K 10
svn:author
V 7
glebius
K 8
svn:date
V 27
2013-12-01T21:10:07.220180Z
K 7
svn:log
V 2457
An attempt of major rewrite of sendfile(2).

The core change is that now we don't use VOP_READ() to fetch pages
from storage to memory, but VOP_GETPAGES() instead.

This was considered by David Greenman in original implementation in 1998,
but he decided to use VOP_READ(), to utilize read ahead provided by FFS.
Apparently, from a pure Mach VM view that choice wasn't a correct one, but
worked for a decade and a half.  Recently, investigations from Scott Long
have shown that:
  a) sendfile(2) leaves touched pages cached by buf layer, they are wired,
and at a high load, buf layer can hold them too long, so that a pagedaemon
sweep starts.
  b) the readahead heuristic from FFS isn't enough, and better provide a
manual static readahead to the sendfile itself via a global sysctl.

Changes:

1) sendfile_readpage() goes away entirely.
2) sendfile_swapin() emerges.  This function takes array of vm_pages,
   that needs to be fetched from storage to wired memory.  The function
   iterates through pages, gets a readahead hint from vm_pager_has_page(),
   and then asks vm_page_get_pages() for a block of pages.

   Notice, that sendfile_swapin() doesn't differentiate between vnode backed
   descriptors and shared memory backed, like old code used to.

   Also notice, that function is a pure VM function, and can be moved to
   sys/vm, being renamed.

   For now function ignores configured readahead sysctl.

3) Main vn_sendfile() cycle gets simplier.
   - Outer cycle is driven by the "rem" variable, that is initialized at the
     beginning and shrinks as we go forward.  The only exception for "rem" to
     unexpectedly change its value is a file resize.
   - Inner cycle is driven by number of pages, and number of pages is
     calculated as minimum of available space in socket and "rem".

Basic performance testing showed no regressions in timing. Number of I/Os
decreased comparing to sendfile() from head, but increased compared to
previous version of the projects/sendfile.  On a sample 300 Mb file:

                	I/Os
head            	3247
projects/sendfile        680
new code           	2826

A file fetched immediately gets into inactive memory. Top quote from
head, after reboot and fetch of a 300 Mb file:

  Mem: 26M Active, 192M Inact, 177M Wired, 159M Buf, 588M Free

And from new code:

  Mem: 25M Active, 320M Inact, 46M Wired, 22M Buf, 592M Free

In collaboration with:	kib
Sponsored by:		Netflix
Sponsored by:		Nginx, Inc.

END