On Wed, 2013-01-02 at 20:47 +0000, Eric Wong wrote:
> Eric Wong <normalper...@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 ?
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'
diff --git a/toosleepy.c b/toosleepy.c
index e64b7cd..df3610f 100644
--- a/toosleepy.c
+++ b/toosleepy.c
@@ -15,6 +15,7 @@
#include <fcntl.h>
#include <assert.h>
#include <limits.h>
+#include <time.h>
struct receiver {
int rfd;
@@ -53,6 +54,7 @@ static void * recv_loop(void *p)
ssize_t r, s;
size_t received = 0;
size_t sent = 0;
+ time_t t0 = time(NULL), t1;
for (;;) {
r = recv(rcvr->rfd, buf, sizeof(buf), 0);
@@ -80,9 +82,12 @@ static void * recv_loop(void *p)
write(-1, buf, sizeof(buf));
}
}
- if ((received % (sizeof(buf) * sizeof(buf) * 16) == 0))
+ t1 = time(NULL);
+ if (t1 != t0) {
dprintf(2, " %d progress: %zu\n",
rcvr->rfd, received);
+ t0 = t1;
+ }
}
dprintf(2, "%d got: %zu\n", rcvr->rfd, received);
if (rcvr->sfd >= 0) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
