On 12/14/2015 03:27 AM, Raghavendra Gowdappa wrote:
----- Original Message -----
From: "Joe Julian" <[email protected]>
To: "Gluster Devel" <[email protected]>
Sent: Monday, December 14, 2015 2:40:14 PM
Subject: [Gluster-devel] 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
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-devel
