Commit Graph

3 Commits

Author SHA1 Message Date
Alan Cox
a5819cb5b5 Don't remove the virtual-to-physical mapping when an sf_buf is freed.
Instead, allow the mapping to persist, but add the sf_buf to a free list.
If a later sendfile(2) or zero-copy send resends the same physical page,
perhaps with the same or different contents, then the mapping overhead is
avoided and the sf_buf is simply removed from the free list.

In other words, the i386 sf_buf implementation now behaves as a cache of
virtual-to-physical translations using an LRU replacement policy on
inactive sf_bufs.  This is similar in concept to a part of
http://www.cs.princeton.edu/~yruan/debox/ patch, but much simpler in
implementation.  Note: none of this is required on alpha, amd64, or ia64.
They now use their direct virtual-to-physical mapping to avoid any
emphemeral mapping overheads in their sf_buf implementations.
2003-12-07 22:49:25 +00:00
Alan Cox
0543fa5398 - Change the i386's sf_buf implementation so that it never allocates
more than one sf_buf for one vm_page.  To accomplish this, we add
   a global hash table mapping vm_pages to sf_bufs and a reference
   count to each sf_buf.  (This is similar to the patches for RELENG_4
   at http://www.cs.princeton.edu/~yruan/debox/.)

   For the uninitiated, an sf_buf is nothing more than a kernel virtual
   address that is used for temporary virtual-to-physical mappings by
   sendfile(2) and zero-copy sockets.  As such, there is no reason for
   one vm_page to have several sf_bufs mapping it.  In fact, using more
   than one sf_buf for a single vm_page increases the likelihood that
   sendfile(2) blocks, hurting throughput.
   (See http://www.cs.princeton.edu/~yruan/debox/.)
2003-11-17 18:22:24 +00:00
Alan Cox
e45db9b837 - Modify alpha's sf_buf implementation to use the direct virtual-to-
physical mapping.
 - Move the sf_buf API to its own header file; make struct sf_buf's
   definition machine dependent.  In this commit, we remove an
   unnecessary field from struct sf_buf on the alpha, amd64, and ia64.
   Ultimately, we may eliminate struct sf_buf on those architecures
   except as an opaque pointer that references a vm page.
2003-11-16 06:11:26 +00:00