Thread (29 messages) 29 messages, 7 authors, 2006-12-01

Re: [patch 1/4] - Potential performance bottleneck for Linxu TCP

From: David Miller <davem@davemloft.net>
Date: 2006-11-30 02:19:53
Also in: lkml

From: Wenji Wu <redacted>
Date: Wed, 29 Nov 2006 19:56:58 -0600
quoted
We could also pepper tcp_recvmsg() with some very carefully placed
preemption disable/enable calls to deal with this even with
CONFIG_PREEMPT enabled.
I also think about this approach. But since the "problem" happens in
the 2.6 Desktop and Low-latency Desktop (not server), system
responsiveness is a key feature, simply placing preemption
disabled/enable call might not work.  If you want to place
preemption disable/enable calls within tcp_recvmsg, you have to put
them in the very beginning and end of the call. Disabling preemption
would degrade system responsiveness.
We can make explicitl preemption checks in the main loop of
tcp_recvmsg(), and release the socket and run the backlog if
need_resched() is TRUE.

This is the simplest and most elegant solution to this problem.

The one suggested in your patch and paper are way overkill, there is
no reason to solve a TCP specific problem inside of the generic
scheduler.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help