diff options
author | Shyam <srangana@redhat.com> | 2015-01-26 14:20:31 -0500 |
---|---|---|
committer | Vijay Bellur <vbellur@redhat.com> | 2015-02-07 13:23:03 -0800 |
commit | a7f5893c9243c8c563db215352fa7e47f6968e8b (patch) | |
tree | 27feeeb5888accae0763593b489373cff1436d6a /libglusterfs/src/compat-errno.h | |
parent | c61074400a45e69c6edbf82b8ed02568726d37ae (diff) | |
download | glusterfs-a7f5893c9243c8c563db215352fa7e47f6968e8b.tar.gz glusterfs-a7f5893c9243c8c563db215352fa7e47f6968e8b.tar.xz glusterfs-a7f5893c9243c8c563db215352fa7e47f6968e8b.zip |
epoll: Adding the ability to configure epoll threads
Add the ability to configure the number of event threads
for various gluster services.
Currently with the multi thread epoll patch, it is possible
to have more than one thread waiting on socket activity and
processing the same. This thread count is currently static,
which this commit makes dynamic.
The current services which use IO path, i.e brick processes,
any client process (nfs, FUSE, gfapi, heal,
rebalance, etc.a), gain 2 set parameters to control the number
of threads that are processing events. These settings are,
- client.event-threads <n>
- server.event-threads <n>
The client setting affects the client graph consumers, and the
server setting affects the brick processes. These are processed
and inited/reconfigured using the client/server protocol xlators.
Other services (say glusterd) would need to extend similar
configuration settings to take advantage of multi threaded event
processing.
At present glusterd is not enabled with this commit, as it does not
stand to gain from this multi-threading (as I understand it).
Change-Id: Id8422fc57a9f95a135158eb6477ccf9d3c9ea4d9
BUG: 1104462
Signed-off-by: Shyam <srangana@redhat.com>
Reviewed-on: http://review.gluster.org/9488
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Diffstat (limited to 'libglusterfs/src/compat-errno.h')
0 files changed, 0 insertions, 0 deletions