tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rsync very slow with current kernel (select issue?)

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  
  4102      1 rsync    1311780579.483436279 RET   select 0
  4102      1 rsync    1311780579.483440327 CALL  
  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.


Michael L. Hitch              
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA

Home | Main Index | Thread Index | Old Index