Messages in this thread | | | Date | Thu, 3 Jan 2013 18:32:51 +0000 | From | Eric Wong <> | Subject | Re: ppoll() stuck on POLLIN while TCP peer is sending |
| |
Eric Dumazet <eric.dumazet@gmail.com> wrote: > On Wed, 2013-01-02 at 20:47 +0000, Eric Wong wrote: > > Eric Wong <normalperson@yhbt.net> wrote: > > > [1] my full setup is very strange. > > > > > > Other than the FUSE component I forgot to mention, little depends on > > > the kernel. With all this, the standalone toosleepy can get stuck. > > > I'll try to reproduce it with less... > > > > I just confirmed my toosleepy processes will get stuck while just > > doing "rsync -a" between local disks. So this does not depend on > > sendfile or FUSE to reproduce. > > -- > > How do you tell your 'toosleepy' is stuck ?
My original post showed it stuck with strace (in ppoll + send). I only strace after seeing it's not using any CPU in top.
http://mid.gmane.org/20121228014503.GA5017@dcvr.yhbt.net (lsof also confirmed the ppoll/send sockets were peers)
> If reading its output, you should change its logic, there is no > guarantee the recv() will deliver exactly 16384 bytes each round. > > With the following patch, I cant reproduce the 'apparent stuck'
Right, the output is just an approximation and the logic there was bogus.
Thanks for looking at this.
| |