On Wed, 27 Jul 2011, Manuel Bouyer wrote:
Some investigations makes me suspect that select(2) is not working
properly, especially it doesn't wake up when there's data ready in the
socket buffer: when the rsync process is idle it's waiting on select,
when it's idle netstat shows that the receive socket queue is full (I
tried with both net.inet.tcp.recvbuf_auto set to 1 and 0) and
ktrace shows:
4102 1 rsync 1311780519.324063908 CALL
select(4,0x7f7fffff83b0,0x7f7fffff8390,0,0x7f7fffff83d0)
4102 1 rsync 1311780579.483436279 RET select 0
4102 1 rsync 1311780579.483440327 CALL
select(4,0x7f7fffff83b0,0x7f7fffff8390,0,0x7f7fffff83d0)
4102 1 rsync 1311780579.483442445 RET select 1
4102 1 rsync 1311780579.483443326 CALL read(3,0x7f7ff7a36de2,0x21a)
4102 1 rsync 1311780579.483451341 GIO fd 3 read 538 bytes
So select blocks (maybe because there's effectively nothing to read at this
time), but instead of waking up when there's data ready it wakes up
when the timeout expires. The next select call returns immediatly.
Does it ring a bell to someone ? Any recent change in this area
(either in select(2), or tcp) recently ?
This seems rather similar to something I was looking at back in January.
I remembered digging through that socket code trying to figure out what it
was doing. The specific problem was "weird ping statistics" on a vax, and
it seems like that was showing something similar - the echo response
should have been received and have woken up the ping process, but it
didn't seem to do that and the pine process didn't get scheduled until
another cpu-bound process had run a couple of 100ms schedule intervals.
Mike
--
Michael L. Hitch mhi...@montana.edu
Computer Consultant
Information Technology Center
Montana State University Bozeman, MT USA
