On Mon, Dec 14, 2015 at 9:43 PM, Joe Julian <[email protected]> wrote:
> > > 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? 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 >>> [email protected] >>> http://www.gluster.org/mailman/listinfo/gluster-devel >>> >>> > _______________________________________________ > Gluster-devel mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-devel > -- Raghavendra G
_______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
