<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 9:43 PM, Joe Julian <span dir="ltr"><<a href="mailto:joe@julianfamily.org" target="_blank">joe@julianfamily.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 12/14/2015 03:27 AM, Raghavendra Gowdappa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
----- Original Message -----<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: "Joe Julian" <<a href="mailto:joe@julianfamily.org" target="_blank">joe@julianfamily.org</a>><br>
To: "Gluster Devel" <<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>><br>
Sent: Monday, December 14, 2015 2:40:14 PM<br>
Subject: [Gluster-devel] Is there any advantage or disadvantage to multiple cpu cores?<br>
<br>
Does the code take advantage of multiple cpu cores?<br>
</blockquote>
On client:<br>
* We've multiple threads to receive replies from bricks parallely (multithreaded epoll).<br>
* the thread that reads from /dev/fuse doesn't generally process replies. So, request and reply processing can happen parallely.<br>
<br>
On Bricks:<br>
* io-threads enables parallelism for processing all request/reply parallely.<br>
</blockquote>
<br></span>
Does this have any advantage if you only have a single io path, or would you need multiple sas/sata controllers to take advantage?</blockquote><div><br></div><div>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.<br><br></div><div>Can you elaborate on having multiple sas/sata controllers? I didn't understand the use-case here.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So, we've multiple threads that can execute on multiple cores simultaneously. However, we've don't really assign threads to cores.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If I assigned a single core to gluster, would it have an effect on<br>
performance?<br>
</blockquote>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If yes, explain so I can determine a sane number of cores to allocate<br>
per server.<br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></blockquote>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Raghavendra G<br></div>
</div></div>