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

[Raghavendra G]

On Mon, Dec 14, 2015 at 9:43 PM, Joe Julian <joe at julianfamily.org> wrote:

>
>
> 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?


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 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
>>>
>>>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20151215/5cf8abcc/attachment-0001.html>