Patches ....

11/9/01 - Integrated pipe patch for 2.4.14 Manfred Spraul zerocopy and Hubertus Franke large pipe patch.  

11/8/01 - Spinlock patch. This patch aligns the 5 locks:

• kmap_lock
• pagecache_lock
• pagemap_lru_lock
• lru_list_lock
• kernel_flag

according to a cacheline and ensure that the spinlock is the only data in this cacheline. This increases the performance for Dbench with 4 and 8 CPUs.

8/20/01 - IPS patch for Jens Axboe's bounce buffer patch. Two files: ipc.c and ipc.h.

8/1/01 - e1000 patch for zerocopy. This is for version 3.0.10 of the Intel Pro/1000 Gigabit Ethernet driver (e1000). To patch, cd to the ./src directory of the e1000 driver source tree and run "patch -p1 < [patch_file]"

8/1/01 - Sendfile() for Samba 2.2. Uses sendfile() for SMB read requests. Used with zerocopy, can make significant improvements in performance.

7/17/01 - CPU allowed patch. CPU-process affinity by Andrew Morton. Uses /proc similar to IRQ affinty. The value is a mask of the processor numbers (P1==1, P2==2, P3==4, Pi=2**(i-1) ), encoded in hex. For example, to bind a process $pid to processors 1 or 3 do the following:

echo "05" > /proc/$pid/cpus_allowed

or to bind it to processors 8 or 3 do the following:

echo "0b" > /proc/$pid/cpus_allowed

or to allow it to execute on any processor do

echo "ffffffff" > /proc/$pid/cpus_allowed

7/17/01 - Low (variable) ack delay. This patch was built against plain vanilla Linux-2.4.4. After you have applied it, you will find a new variable in /proc/sys/net/ipv4: tcp_delack_max. The default value is Hz/5 which is usually 20 on most systems. You can adjust this value to be lower by doing the following:

echo 10 > /proc/sys/net/ipv4/tcp_delack_max

for instance. The units are in ticks - so the default of 20 implies that the max interval the ack will be delayed is 200ms. By setting it to 10, the max interval is now 100ms, for example. The max value of the ack interval is bounded below by the min delayed ack timeout, which I havent changed for protocol purposes - it is 4 (ticks = 40ms). You should not set tcp_delack_max to lower than that. tcp_delack_max is bounded above by the RTO, so even if you do set tcp_delack_max to a very high value, it will not be used above the RTO max values..but in any case, you will not be increasing this value, only decreasing it, so that shouldnt affect you. The impact of this change is that more acks are generated. So you will see a lot more packets coming out of the receiver. However, if the communication is fairly small sized or interactive, and very uni-directional, then shortening the ack delay time will help.

7/9/01 - kmap lock patch. This patch reduces the CPU utilization for spinning to acquire the kmap_lock. Source: from Mark Hemment on the Lse-tech mailing list (06/15/2001), https://sourceforge.net/projects/lse).

7/9/01 - Page cache lock patch. This patch reduces the CPU utilization for spinning to acquire the pagecache lock. source: from Ingo Molnar's Redhat site (http://people.redhat.com/mingo).

5/19/01 - MQ scheduler patch for 2.4.4. This patch was used for VolanoMark perf analysis