On Mon, Dec 14, 2015 at 9:43 PM, Joe Julian <joe@xxxxxxxxxxxxxxxx> wrote:
On 12/14/2015 03:27 AM, Raghavendra Gowdappa wrote:
----- Original Message -----
From: "Joe Julian" <joe@xxxxxxxxxxxxxxxx>On client:
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?
* 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?
I assume by "single I/O path" you mean that there is only a single application with a single thread running on a single mount. Even in this case, translators like write-behind and open-behind can introduce parallel operations in their child translators.
Can you elaborate on having multiple sas/sata controllers? I didn't understand the use-case here.
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 onLong 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.
performance?
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
--
Raghavendra G
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
