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