Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > On Wed, 2013-01-02 at 20:47 +0000, Eric Wong wrote: > > Eric Wong <normalperson@xxxxxxxx> 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@xxxxxxxxxxxxx (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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>