[Gluster-devel] Is there any advantage or disadvantage to multiple cpu cores?

[Joe Julian]

On 12/14/2015 03:27 AM, Raghavendra Gowdappa wrote:
>
> ----- Original Message -----
>> From: "Joe Julian" <joe at julianfamily.org>
>> To: "Gluster Devel" <gluster-devel at gluster.org>
>> 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
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>