[Bugs] [Bug 1358606] limited throughput with disperse volume over small number of bricks

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1358606



--- Comment #2 from Raghavendra G <rgowdapp at redhat.com> ---
>From the discussion I had with Pranith and Manoj, the issue seems to be the way
sockets are added/removed to/from polling for events while higher layers
(socket, programs like glusterfs client) are processing a single event. The
current workflow when an event is received is:

1. There is an incoming msg on socket s. A pollin event is received in epoll
layer.
2. epoll removes the socket from the poll_array. So, we don't receive any more
events on socket "s", till it is added back for polling.
3. Now the handler for pollin is called. This handler
   3a. reads the entire msg from socket (we assume the entire rpc msg is
available).
   3b. Invokes a notification function to higher layers that a msg is received.
Once this this notification call returns handler returns control to epoll
layer. However as part of this notification function higher layers (like EC)
can do significant work, making the time taken by handler a significant chunk.
4. Once handler returns epoll layer adds the socket back for polling and new
events on the socket "s" can be received.

The hypothesis is that "handler" in step 3 is taking more time and hence
delaying reading of more responses on the same socket "s". If there are more
files on the brick socket "s" is connecting to, there is a contention resulting
in the slow down of file operations.

I'll send out a patch to make sure that the socket is added back for polling
just after reading the msg from socket, but before we hand over the msg to
higher layers for processing.

regards,
Raghavendra

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.