[4179] in linux-net channel archive
Re: TCP/buffering changes
daemon@ATHENA.MIT.EDU (Pedro Roque Marques)
Sat Aug 24 10:37:09 1996
Date: Sat, 24 Aug 1996 15:11:26 +0100
From: Pedro Roque Marques <roque@di.fc.ul.pt>
To: Linus Torvalds <torvalds@cs.helsinki.fi>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-net@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.91.960824100012.14475C-100000@linux.cs.Helsinki.FI>
>>>>> "Linus" == Linus Torvalds <torvalds@cs.helsinki.fi> writes:
Linus> On Fri, 23 Aug 1996, Darren Crane wrote:
>> Something between 2.0.10 and 2.0.11 slowed samba down.
>>
>> I'm running samba with the following socket options... read
>> prediction = True read size = 4096 socket options =
>> IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=4096 SO_RCVBUF=32768
Linus> You _definitely_ want SNDBUF to be a lot more than
Linus> 4096. The _minimum_ value that makes sense is somewhere
Linus> around 32kB (the default is 64kB).
Maybe the ioctl should take skb overhead into account ...
something like
sndbuf = requested + (requested / 1024) + sizeof(struct sk_buff)
Linus> Ok, 2.0.11 did change the way we sleep on write buffer full
Linus> conditions, so there is _something_ in the buffering. But
Linus> please make sure that you don't have a SNDBUF of 4096 (did
Linus> you re-start samba completely after changing the SNDBUF
Linus> stuff?)
There is a possible error:
sock_wmalloc tests for sk->wmem + sizeof segment < sk->sndbuf
if it fails the socket will be put to sleep
but the wait_for_memory test is sk->wmem < sk->sndbuf (i.e. doesn't
take the sizeof a new skb into account).
This can result in busy waiting of that process in a loop.
./Pedro.
