Re: [fuse-devel] fuse scalability part 1

[Miklos Szeredi <miklos@szeredi.hu>]

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