Messages in this thread | | | Date | Thu, 24 Sep 2015 08:30:47 +0200 | Subject | Re: [fuse-devel] fuse scalability part 1 | From | Miklos Szeredi <> |
| |
On Fri, Aug 14, 2015 at 12:14 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote: > On Mon, May 18, 2015 at 05:13:36PM +0200, Miklos Szeredi wrote: >> This part splits out an "input queue" and a "processing queue" from the >> monolithic "fuse connection", each of those having their own spinlock. >> >> The end of the patchset adds the ability to "clone" a fuse connection. This >> means, that instead of having to read/write requests/answers on a single fuse >> device fd, the fuse daemon can have multiple distinct file descriptors open. >> Each of those can be used to receive requests and send answers, currently the >> only constraint is that a request must be answered on the same fd as it was read >> from. >> >> This can be extended further to allow binding a device clone to a specific CPU >> or NUMA node. > > How will requests be distributed across clones? > > Is the idea here to start one clone per core and have IO requests > originating from one core to be processed by the fuse clone on the > same core? I remember there was a noticeable speedup when request and > processing where on the same core. > > How is the clone for each request choosen? What if there is no clone > pinned to the same core? Will it pick the clone nearest in NUMA terms? > Will it round-robin? Will it load balance to the clone with least > number of requests pending? What if one clone stops processing requests?
Good questions. I guess, first implementation should be the simplest possible. E.g. use the queue that matches (in this order):
- CPU - NUMA node - any (round robin or whatever)
I woudn't worry about load balancing and unresponsive queues until such issues come up in real life.
Thanks, Miklos
| |