[EMAIL PROTECTED] wrote on Wed, 03 Oct 2007 09:52 -0500:
> Tried that. :-) Its more or less the same problem with poll. The
> behavior of poll timings seems a bit less erratic than with epoll,
> but the performance degradation is identical.
[..]
> >>Its a PITA to debug, because the servers have to remain running for a
> >>long time (and the clients have to remain mounted) for the problem to
> >>be visible. Rob suggested I use strace on the servers to see what
> >>epoll was doing, and that showed some interesting results.
> >>Basically, it looks like epoll_wait takes significantly longer when
> >>clients are doing operations over the VFS, rather than with the pvfs2
> >>admin tools. Also, strace reported epoll_ctl(...,
> >>EPOLL_CTL_ADD, ...)) getting called a few times, even for the VFS
> >>ops, and in those cases its returning EEXISTS.
Really? Poll also behaves the same? Now I am intrigued.
You can't really tell how long epoll_wait is taking just using
strace, since it will wait until a packet arrives plus this
mysterious extra time.
Can you do something on the server like:
tcpdump -ttt
strace -tt -T
to distinguish the two cases of 1) epoll_wait is taking a long time
after the packet shows up at the host, vs 2) the client request
packet is taking a long time to show up.
If (2), try the same exercise at the client side.
I'm sure some of us will look at the traces and dumps too, if you
send them out.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
