00000006.htm

一份很好的linux入门资料

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ulimit&nbsp;-n&nbsp;32768&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;increases&nbsp;the&nbsp;current&nbsp;process'&nbsp;limit.&nbsp;I&nbsp;verified&nbsp;that&nbsp;a&nbsp;process&nbsp;&nbsp;<BR>
on&nbsp;Red&nbsp;Hat&nbsp;6.0&nbsp;(2.2.5&nbsp;or&nbsp;so&nbsp;plus&nbsp;patches)&nbsp;can&nbsp;open&nbsp;at&nbsp;least&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;31000&nbsp;file&nbsp;descriptors&nbsp;this&nbsp;way.&nbsp;Another&nbsp;fellow&nbsp;has&nbsp;verified&nbsp;that&nbsp;a&nbsp;<BR>
&nbsp;process&nbsp;on&nbsp;2.2.12&nbsp;can&nbsp;open&nbsp;at&nbsp;least&nbsp;90000&nbsp;file&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;descriptors&nbsp;this&nbsp;way&nbsp;(with&nbsp;appropriate&nbsp;limits).&nbsp;The&nbsp;upper&nbsp;bound&nbsp;&nbsp;<BR>
seems&nbsp;to&nbsp;be&nbsp;available&nbsp;memory.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Stephen&nbsp;C.&nbsp;Tweedie&nbsp;posted&nbsp;about&nbsp;how&nbsp;to&nbsp;set&nbsp;ulimit&nbsp;limits&nbsp;globally&nbsp;&nbsp;<BR>
or&nbsp;per-user&nbsp;at&nbsp;boot&nbsp;time&nbsp;using&nbsp;initscript&nbsp;and&nbsp;pam_limit.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In&nbsp;older&nbsp;2.2&nbsp;kernels,&nbsp;though,&nbsp;the&nbsp;number&nbsp;of&nbsp;open&nbsp;files&nbsp;per&nbsp;&nbsp;<BR>
process&nbsp;is&nbsp;still&nbsp;limited&nbsp;to&nbsp;1024,&nbsp;even&nbsp;with&nbsp;the&nbsp;above&nbsp;changes.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;See&nbsp;also&nbsp;Oskar's&nbsp;1998&nbsp;post,&nbsp;which&nbsp;talks&nbsp;about&nbsp;the&nbsp;per-process&nbsp;and&nbsp;&nbsp;<BR>
system-wide&nbsp;limits&nbsp;on&nbsp;file&nbsp;descriptors&nbsp;in&nbsp;the&nbsp;2.0.36&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;kernel.&nbsp;&nbsp;<BR>
&nbsp;<BR>
Limits&nbsp;on&nbsp;threads&nbsp;<BR>
&nbsp;<BR>
On&nbsp;any&nbsp;architecture,&nbsp;you&nbsp;may&nbsp;need&nbsp;to&nbsp;reduce&nbsp;the&nbsp;amount&nbsp;of&nbsp;stack&nbsp;space&nbsp;&nbsp;<BR>
allocated&nbsp;for&nbsp;each&nbsp;thread&nbsp;to&nbsp;avoid&nbsp;running&nbsp;out&nbsp;of&nbsp;virtual&nbsp;<BR>
memory.&nbsp;You&nbsp;can&nbsp;set&nbsp;this&nbsp;at&nbsp;runtime&nbsp;with&nbsp;pthread_attr_init()&nbsp;if&nbsp;you're&nbsp;&nbsp;<BR>
using&nbsp;pthreads.&nbsp;&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Solaris:&nbsp;it&nbsp;supports&nbsp;as&nbsp;many&nbsp;threads&nbsp;as&nbsp;will&nbsp;fit&nbsp;in&nbsp;memory,&nbsp;I&nbsp;hear.&nbsp;<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FreeBSD:&nbsp;?&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Linux:&nbsp;Even&nbsp;the&nbsp;2.2.13&nbsp;kernel&nbsp;limits&nbsp;the&nbsp;number&nbsp;of&nbsp;threads,&nbsp;at&nbsp;&nbsp;<BR>
least&nbsp;on&nbsp;Intel.&nbsp;I&nbsp;don't&nbsp;know&nbsp;what&nbsp;the&nbsp;limits&nbsp;are&nbsp;on&nbsp;other&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;architectures.&nbsp;Mingo&nbsp;posted&nbsp;a&nbsp;patch&nbsp;for&nbsp;2.1.131&nbsp;on&nbsp;Intel&nbsp;that&nbsp;&nbsp;<BR>
removed&nbsp;this&nbsp;limit.&nbsp;It&nbsp;appears&nbsp;to&nbsp;be&nbsp;integrated&nbsp;into&nbsp;2.3.20.&nbsp;&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;See&nbsp;also&nbsp;Volano's&nbsp;detailed&nbsp;instructions&nbsp;for&nbsp;raising&nbsp;file,&nbsp;thread,&nbsp;&nbsp;<BR>
and&nbsp;FD_SET&nbsp;limits&nbsp;in&nbsp;the&nbsp;2.2&nbsp;kernel.&nbsp;Wow.&nbsp;This&nbsp;stunning&nbsp;little&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;document&nbsp;steps&nbsp;you&nbsp;through&nbsp;a&nbsp;lot&nbsp;of&nbsp;stuff&nbsp;that&nbsp;would&nbsp;be&nbsp;hard&nbsp;to&nbsp;&nbsp;<BR>
figure&nbsp;out&nbsp;yourself.&nbsp;This&nbsp;is&nbsp;a&nbsp;must-read,&nbsp;even&nbsp;though&nbsp;some&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;its&nbsp;advice&nbsp;is&nbsp;already&nbsp;out&nbsp;of&nbsp;date.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Java:&nbsp;See&nbsp;Volano's&nbsp;detailed&nbsp;benchmark&nbsp;info,&nbsp;plus&nbsp;their&nbsp;info&nbsp;on&nbsp;&nbsp;<BR>
how&nbsp;to&nbsp;tune&nbsp;various&nbsp;systems&nbsp;to&nbsp;handle&nbsp;lots&nbsp;of&nbsp;threads.&nbsp;&nbsp;<BR>
&nbsp;<BR>
Other&nbsp;limits/tips&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;select()&nbsp;is&nbsp;limited&nbsp;to&nbsp;FD_SETSIZE&nbsp;handles.&nbsp;This&nbsp;limit&nbsp;is&nbsp;compiled&nbsp;&nbsp;<BR>
in&nbsp;to&nbsp;the&nbsp;standard&nbsp;library&nbsp;and&nbsp;user&nbsp;programs.&nbsp;The&nbsp;similar&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;call&nbsp;poll()&nbsp;does&nbsp;not&nbsp;have&nbsp;a&nbsp;comparable&nbsp;limit,&nbsp;and&nbsp;can&nbsp;have&nbsp;less&nbsp;&nbsp;<BR>
overhead&nbsp;than&nbsp;select().&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Old&nbsp;system&nbsp;libraries&nbsp;might&nbsp;use&nbsp;16&nbsp;bit&nbsp;variables&nbsp;to&nbsp;hold&nbsp;file&nbsp;&nbsp;<BR>
handles,&nbsp;which&nbsp;causes&nbsp;trouble&nbsp;above&nbsp;32767&nbsp;handles.&nbsp;glibc2.1&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;should&nbsp;be&nbsp;ok.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Many&nbsp;systems&nbsp;use&nbsp;16&nbsp;bit&nbsp;variables&nbsp;to&nbsp;hold&nbsp;process&nbsp;or&nbsp;thread&nbsp;id's.&nbsp;&nbsp;<BR>
It&nbsp;would&nbsp;be&nbsp;interesting&nbsp;to&nbsp;port&nbsp;the&nbsp;Volano&nbsp;scalability&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;benchmark&nbsp;to&nbsp;C,&nbsp;and&nbsp;see&nbsp;what&nbsp;the&nbsp;upper&nbsp;limit&nbsp;on&nbsp;number&nbsp;of&nbsp;threads&nbsp;&nbsp;<BR>
is&nbsp;for&nbsp;the&nbsp;various&nbsp;operating&nbsp;systems.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Too&nbsp;much&nbsp;thread-local&nbsp;memory&nbsp;is&nbsp;preallocated&nbsp;by&nbsp;some&nbsp;operating&nbsp;&nbsp;<BR>
systems;&nbsp;if&nbsp;each&nbsp;thread&nbsp;gets&nbsp;1MB,&nbsp;and&nbsp;total&nbsp;VM&nbsp;space&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;is&nbsp;2GB,&nbsp;that&nbsp;creates&nbsp;an&nbsp;upper&nbsp;limit&nbsp;of&nbsp;2000&nbsp;threads.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Normally,&nbsp;data&nbsp;gets&nbsp;copied&nbsp;many&nbsp;times&nbsp;on&nbsp;its&nbsp;way&nbsp;from&nbsp;here&nbsp;to&nbsp;&nbsp;<BR>
there.&nbsp;mmap()&nbsp;and&nbsp;sendfile()&nbsp;can&nbsp;be&nbsp;used&nbsp;to&nbsp;reduce&nbsp;this&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;overhead&nbsp;in&nbsp;some&nbsp;cases.&nbsp;IO-Lite&nbsp;is&nbsp;a&nbsp;proposal&nbsp;(already&nbsp;&nbsp;<BR>
implemented&nbsp;on&nbsp;FreeBSD)&nbsp;for&nbsp;a&nbsp;set&nbsp;of&nbsp;I/O&nbsp;primitives&nbsp;that&nbsp;gets&nbsp;rid&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;the&nbsp;need&nbsp;for&nbsp;many&nbsp;copies.&nbsp;It's&nbsp;sexy;&nbsp;go&nbsp;read&nbsp;it.&nbsp;But&nbsp;see&nbsp;also&nbsp;&nbsp;<BR>
Alan&nbsp;Cox's&nbsp;opinion&nbsp;of&nbsp;zero-copy.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The&nbsp;sendfile()&nbsp;function&nbsp;in&nbsp;Linux&nbsp;and&nbsp;FreeBSD&nbsp;lets&nbsp;you&nbsp;tell&nbsp;the&nbsp;&nbsp;<BR>
kernel&nbsp;to&nbsp;send&nbsp;part&nbsp;or&nbsp;all&nbsp;of&nbsp;a&nbsp;file.&nbsp;This&nbsp;lets&nbsp;the&nbsp;OS&nbsp;do&nbsp;it&nbsp;as&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;efficiently&nbsp;as&nbsp;possible.&nbsp;It&nbsp;can&nbsp;be&nbsp;used&nbsp;equally&nbsp;well&nbsp;in&nbsp;servers&nbsp;&nbsp;<BR>
using&nbsp;threads&nbsp;or&nbsp;servers&nbsp;using&nbsp;nonblocking&nbsp;I/O.&nbsp;(In&nbsp;Linux,&nbsp;It's&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;poorly&nbsp;documented&nbsp;at&nbsp;the&nbsp;moment;&nbsp;use&nbsp;_syscall4&nbsp;to&nbsp;call&nbsp;it.&nbsp;Andi&nbsp;&nbsp;<BR>
Kleen&nbsp;is&nbsp;writing&nbsp;new&nbsp;man&nbsp;pages&nbsp;that&nbsp;cover&nbsp;this.)&nbsp;Rumor&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;has&nbsp;it,&nbsp;ftp.cdrom.com&nbsp;benefitted&nbsp;noticably&nbsp;from&nbsp;sendfile().&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A&nbsp;new&nbsp;socket&nbsp;option&nbsp;under&nbsp;Linux,&nbsp;TCP_CORK,&nbsp;tells&nbsp;the&nbsp;kernel&nbsp;to&nbsp;&nbsp;<BR>
avoid&nbsp;sending&nbsp;partial&nbsp;frames,&nbsp;which&nbsp;helps&nbsp;a&nbsp;bit&nbsp;e.g.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;when&nbsp;there&nbsp;are&nbsp;lots&nbsp;of&nbsp;little&nbsp;write()&nbsp;calls&nbsp;you&nbsp;can't&nbsp;bundle&nbsp;&nbsp;<BR>
together&nbsp;for&nbsp;some&nbsp;reason.&nbsp;Unsetting&nbsp;the&nbsp;option&nbsp;flushes&nbsp;the&nbsp;buffer.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Not&nbsp;all&nbsp;threads&nbsp;are&nbsp;created&nbsp;equal.&nbsp;The&nbsp;clone()&nbsp;function&nbsp;in&nbsp;Linux&nbsp;&nbsp;<BR>
(and&nbsp;its&nbsp;friends&nbsp;in&nbsp;other&nbsp;operating&nbsp;systems)&nbsp;lets&nbsp;you&nbsp;create&nbsp;a&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;thread&nbsp;that&nbsp;has&nbsp;its&nbsp;own&nbsp;current&nbsp;working&nbsp;directory,&nbsp;for&nbsp;instance,&nbsp;&nbsp;<BR>
which&nbsp;can&nbsp;be&nbsp;very&nbsp;helpful&nbsp;when&nbsp;implementing&nbsp;an&nbsp;ftp&nbsp;server.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;See&nbsp;Hoser&nbsp;FTPd&nbsp;for&nbsp;an&nbsp;example&nbsp;of&nbsp;the&nbsp;use&nbsp;of&nbsp;native&nbsp;threads&nbsp;rather&nbsp;&nbsp;<BR>
than&nbsp;pthreads.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;To&nbsp;keep&nbsp;the&nbsp;number&nbsp;of&nbsp;filehandles&nbsp;per&nbsp;process&nbsp;down,&nbsp;servers&nbsp;can&nbsp;&nbsp;<BR>
fork()&nbsp;once&nbsp;they&nbsp;reach&nbsp;the&nbsp;desired&nbsp;maximum;&nbsp;the&nbsp;child&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;finishes&nbsp;serving&nbsp;the&nbsp;existing&nbsp;clients,&nbsp;and&nbsp;the&nbsp;parent&nbsp;accepts&nbsp;and&nbsp;&nbsp;<BR>
services&nbsp;new&nbsp;clients.&nbsp;(If&nbsp;the&nbsp;desired&nbsp;maximum&nbsp;is&nbsp;1,&nbsp;this&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;degenerates&nbsp;to&nbsp;the&nbsp;classical&nbsp;one-process-per-client&nbsp;model.)&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;One&nbsp;developer&nbsp;using&nbsp;sendfile()&nbsp;with&nbsp;Freebsd&nbsp;reports&nbsp;that&nbsp;using&nbsp;&nbsp;<BR>
POLLWRBAND&nbsp;instead&nbsp;of&nbsp;POLLOUT&nbsp;makes&nbsp;a&nbsp;big&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;difference.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Look&nbsp;at&nbsp;the&nbsp;performance&nbsp;comparison&nbsp;graph&nbsp;at&nbsp;the&nbsp;bottom&nbsp;of&nbsp;http:&nbsp;<BR>
//www.acme.com/software/thttpd/benchmarks.html.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Notice&nbsp;how&nbsp;various&nbsp;servers&nbsp;have&nbsp;trouble&nbsp;above&nbsp;128&nbsp;connections,&nbsp;even&nbsp;<BR>
&nbsp;on&nbsp;Solaris&nbsp;2.6?&nbsp;Anyone&nbsp;who&nbsp;figures&nbsp;out&nbsp;why,&nbsp;let&nbsp;me&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;know.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Note:&nbsp;if&nbsp;the&nbsp;TCP&nbsp;stack&nbsp;has&nbsp;a&nbsp;bug&nbsp;that&nbsp;causes&nbsp;a&nbsp;short&nbsp;(200ms)&nbsp;&nbsp;<BR>
delay&nbsp;at&nbsp;SYN&nbsp;or&nbsp;FIN&nbsp;time,&nbsp;as&nbsp;Linux&nbsp;2.2.0-2.2.6&nbsp;had,&nbsp;and&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;OS&nbsp;or&nbsp;http&nbsp;daemon&nbsp;has&nbsp;a&nbsp;hard&nbsp;limit&nbsp;on&nbsp;the&nbsp;number&nbsp;of&nbsp;connections&nbsp;<BR>
&nbsp;open,&nbsp;you&nbsp;would&nbsp;expect&nbsp;exactly&nbsp;this&nbsp;behavior.&nbsp;There&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;may&nbsp;be&nbsp;other&nbsp;causes.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;Re:&nbsp;fix&nbsp;for&nbsp;hybrid&nbsp;server&nbsp;problems&quot;&nbsp;by&nbsp;Vivek&nbsp;Sadananda&nbsp;Pai&nbsp;&nbsp;<BR>
(<A HREF="mailto:[e-mail])">[e-mail])</A>&nbsp;on&nbsp;new-httpd,&nbsp;May&nbsp;9th,&nbsp;notes:&nbsp;&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;I've&nbsp;compared&nbsp;the&nbsp;raw&nbsp;performance&nbsp;of&nbsp;a&nbsp;select-based&nbsp;server&nbsp;&nbsp;<BR>
with&nbsp;a&nbsp;multiple-process&nbsp;server&nbsp;on&nbsp;both&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FreeBSD&nbsp;and&nbsp;Solaris/x86.&nbsp;On&nbsp;microbenchmarks,&nbsp;there's&nbsp;only&nbsp;a&nbsp;&nbsp;<BR>
marginal&nbsp;difference&nbsp;in&nbsp;performance&nbsp;stemming&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from&nbsp;the&nbsp;software&nbsp;architecture.&nbsp;The&nbsp;big&nbsp;performance&nbsp;win&nbsp;for&nbsp;&nbsp;<BR>
select-based&nbsp;servers&nbsp;stems&nbsp;from&nbsp;doing&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;application-level&nbsp;caching.&nbsp;While&nbsp;multiple-process&nbsp;servers&nbsp;&nbsp;<BR>
can&nbsp;do&nbsp;it&nbsp;at&nbsp;a&nbsp;higher&nbsp;cost,&nbsp;it's&nbsp;harder&nbsp;to&nbsp;get&nbsp;the&nbsp;same&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;benefits&nbsp;on&nbsp;real&nbsp;workloads&nbsp;(vs&nbsp;microbenchmarks).&nbsp;I'll&nbsp;be&nbsp;&nbsp;<BR>
presenting&nbsp;those&nbsp;measurements&nbsp;as&nbsp;part&nbsp;of&nbsp;a&nbsp;paper&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;that'll&nbsp;appear&nbsp;at&nbsp;the&nbsp;next&nbsp;Usenix&nbsp;conference.&nbsp;If&nbsp;you've&nbsp;got&nbsp;&nbsp;<BR>
postscript,&nbsp;the&nbsp;paper&nbsp;is&nbsp;available&nbsp;at&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://www.cs.rice.edu/~vivek/flash99/"">http://www.cs.rice.edu/~vivek/flash99/"</A>&nbsp;&nbsp;<BR>
&nbsp;<BR>
Kernel&nbsp;Issues&nbsp;<BR>
&nbsp;<BR>
For&nbsp;Linux,&nbsp;it&nbsp;looks&nbsp;like&nbsp;kernel&nbsp;bottlenecks&nbsp;are&nbsp;being&nbsp;fixed&nbsp;constantly.&nbsp;<BR>
&nbsp;See&nbsp;Linux&nbsp;HQ,&nbsp;Kernel&nbsp;Traffic,&nbsp;and&nbsp;the&nbsp;Linux-Kernel&nbsp;mailing&nbsp;<BR>
list&nbsp;(Example&nbsp;interesting&nbsp;posts&nbsp;by&nbsp;a&nbsp;user&nbsp;asking&nbsp;how&nbsp;to&nbsp;tune,&nbsp;and&nbsp;Dean&nbsp;&nbsp;<BR>