On 12/14/2015 03:27 AM, Raghavendra Gowdappa wrote:
----- Original Message -----
From: "Joe Julian" <joe@xxxxxxxxxxxxxxxx>
To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>
Sent: Monday, December 14, 2015 2:40:14 PM
Subject: Is there any advantage or disadvantage to multiple cpu cores?
Does the code take advantage of multiple cpu cores?
On client:
* We've multiple threads to receive replies from bricks parallely (multithreaded epoll).
* the thread that reads from /dev/fuse doesn't generally process replies. So, request and reply processing can happen parallely.
On Bricks:
* io-threads enables parallelism for processing all request/reply parallely.
Does this have any advantage if you only have a single io path, or would
you need multiple sas/sata controllers to take advantage?
So, we've multiple threads that can execute on multiple cores simultaneously. However, we've don't really assign threads to cores.
If I assigned a single core to gluster, would it have an effect on
performance?
Long time back there was this proposal to make sure a request gets assigned to a thread executing on the same core on which application issued the syscall. The idea was to minimize too many process context switches on a core and thereby conserve relevancy of cpu-cache. But nothing concrete happened towards that goal.
If yes, explain so I can determine a sane number of cores to allocate
per server.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
