#
222813 |
|
07-Jun-2011 |
attilio |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. Anyway, as long as several structures in the kernel are statically allocated and sized as MAXCPU, it is suggested to keep it as low as possible for the time being.
Technical notes on this commit itself: - More functions to handle with cpuset_t objects are introduced. The most notable are cpusetobj_ffs() (which calculates a ffs(3) for a cpuset_t object), cpusetobj_strprint() (which prepares a string representing a cpuset_t object) and cpusetobj_strscan() (which creates a valid cpuset_t starting from a string representation). - pc_cpumask and pc_other_cpus are target to be removed soon. With the moving from cpumask_t to cpuset_t they are now inefficient and not really useful. Anyway, for the time being, please note that access to pcpu datas is protected by sched_pin() in order to avoid migrating the CPU while reading more than one (possible) word - Please note that size of cpuset_t objects may differ between kernel and userland. While this is not directly related to the patch itself, it is good to understand that concept and possibly use the patch as a reference on how to deal with cpuset_t objects in userland, when accessing kernland members. - KTR_CPUMASK is changed and now is represented through a string, to be set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but private testing has been done until to MAXCPU=128 on a real 8x8x2(htt) machine (amd64).
Please note that the FreeBSD version is not yet bumped because of the upcoming pcpu changes. However, note that this patch is not targeted for MFC.
People to thank for the time spent on this patch: - sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested several revision of the patches and really helped in improving stability of this work. - marius fixed several bugs in the sparc64 implementation and reviewed patches related to ktr. - jeff and jhb discussed the basic approach followed. - kib and marcel made targeted review on some specific part of the patch. - marius, art, nwhitehorn and andreast reviewed MD specific part of the patch. - marius, andreast, gonzo, nwhitehorn and jceel tested MD specific implementations of the patch. - Other people have made contributions on other patches that have been already committed and have been listed separately.
Companies that should be mentioned for having participated at several degrees: - Yahoo! for having offered the machines used for testing on big count of CPUs. - The FreeBSD Foundation for having sponsored my devsummit attendance, which has been instrumental. - Sandvine for having offered offices and infrastructure during development.
(I really hope I didn't forget anyone, if it happened I apologize in advance).
|
#
195940 |
|
29-Jul-2009 |
kib |
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)
|
#
123266 |
|
07-Dec-2003 |
alc |
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.
|
#
122860 |
|
17-Nov-2003 |
alc |
- 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/.)
|
#
122780 |
|
16-Nov-2003 |
alc |
- 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.
|