Commit Graph

5 Commits

Author SHA1 Message Date
Konstantin Belousov
8a5ac5d56f As was done in r195820 for amd64, use clflush for flushing cache lines
when memory page caching attributes changed, and CPU does not support
self-snoop, but implemented clflush, for i386.

Take care of possible mappings of the page by sf buffer by utilizing
the mapping for clflush, otherwise map the page transiently. Amd64
used direct map.

Proposed and reviewed by:  alc
Approved by:   re (kensmith)
2009-07-29 08:49:58 +00:00
Alan Cox
5c0db7c71a Implement support for CPU private mappings within sf_buf_alloc(). 2005-02-13 06:23:13 +00:00
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