d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
f91360b174
freebsd-dev/sys/i386/include/sf_buf.h

65 lines
2.1 KiB
C
Raw Normal View History

- 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
/*-
Implement support for CPU private mappings within sf_buf_alloc().
2005-02-13 06:23:13 +00:00
* Copyright (c) 2003, 2005 Alan L. Cox <alc@cs.rice.edu>
- 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
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
#ifndef _MACHINE_SF_BUF_H_
#define _MACHINE_SF_BUF_H_
Commit the support for removing cpumask_t and replacing it directly with cpuset_t objects. That is going to offer the underlying support for a simple bump of MAXCPU and then support for number of cpus > 32 (as it is today). Right now, cpumask_t is an int, 32 bits on all our supported architecture. cpumask_t on the other side is implemented as an array of longs, and easilly extendible by definition. The architectures touched by this commit are the following: - amd64 - i386 - pc98 - arm - ia64 - XEN while the others are still missing. Userland is believed to be fully converted with the changes contained here. Some technical notes: - This commit may be considered an ABI nop for all the architectures different from amd64 and ia64 (and sparc64 in the future) - per-cpu members, which are now converted to cpuset_t, needs to be accessed avoiding migration, because the size of cpuset_t should be considered unknown - size of cpuset_t objects is different from kernel and userland (this is primirally done in order to leave some more space in userland to cope with KBI extensions). If you need to access kernel cpuset_t from the userland please refer to example in this patch on how to do that correctly (kgdb may be a good source, for example). - Support for other architectures is going to be added soon - Only MAXCPU for amd64 is bumped now The patch has been tested by sbruno and Nicholas Esborn on opteron 4 x 12 pack CPUs. More testing on big SMP is expected to came soon. pluknet tested the patch with his 8-ways on both amd64 and i386. Tested by: pluknet, sbruno, gianni, Nicholas Esborn Reviewed by: jeff, jhb, sbruno
2011-05-05 14:39:14 +00:00
#include <sys/_cpuset.h>
- 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
#include <sys/queue.h>
struct vm_page;
struct sf_buf {
- 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
LIST_ENTRY(sf_buf) list_entry; /* list of buffers */
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
TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */
- 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
struct vm_page *m; /* currently mapped page */
vm_offset_t kva; /* va of mapping */
- 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
int ref_count; /* usage of this mapping */
Implement support for CPU private mappings within sf_buf_alloc().
2005-02-13 06:23:13 +00:00
#ifdef SMP
Commit the support for removing cpumask_t and replacing it directly with cpuset_t objects. That is going to offer the underlying support for a simple bump of MAXCPU and then support for number of cpus > 32 (as it is today). Right now, cpumask_t is an int, 32 bits on all our supported architecture. cpumask_t on the other side is implemented as an array of longs, and easilly extendible by definition. The architectures touched by this commit are the following: - amd64 - i386 - pc98 - arm - ia64 - XEN while the others are still missing. Userland is believed to be fully converted with the changes contained here. Some technical notes: - This commit may be considered an ABI nop for all the architectures different from amd64 and ia64 (and sparc64 in the future) - per-cpu members, which are now converted to cpuset_t, needs to be accessed avoiding migration, because the size of cpuset_t should be considered unknown - size of cpuset_t objects is different from kernel and userland (this is primirally done in order to leave some more space in userland to cope with KBI extensions). If you need to access kernel cpuset_t from the userland please refer to example in this patch on how to do that correctly (kgdb may be a good source, for example). - Support for other architectures is going to be added soon - Only MAXCPU for amd64 is bumped now The patch has been tested by sbruno and Nicholas Esborn on opteron 4 x 12 pack CPUs. More testing on big SMP is expected to came soon. pluknet tested the patch with his 8-ways on both amd64 and i386. Tested by: pluknet, sbruno, gianni, Nicholas Esborn Reviewed by: jeff, jhb, sbruno
2011-05-05 14:39:14 +00:00
cpuset_t cpumask; /* cpus on which mapping is valid */
Implement support for CPU private mappings within sf_buf_alloc().
2005-02-13 06:23:13 +00:00
#endif
- 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
};
static __inline vm_offset_t
sf_buf_kva(struct sf_buf *sf)
{
return (sf->kva);
}
static __inline struct vm_page *
sf_buf_page(struct sf_buf *sf)
{
return (sf->m);
}
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
boolean_t sf_buf_invalidate_cache(vm_page_t m);
- 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
#endif /* !_MACHINE_SF_BUF_H_ */
Reference in New Issue Copy Permalink