Re: [fuse-devel] fuse scalability part 1

From: Miklos Szeredi
Date: Thu Sep 24 2015 - 02:30:53 EST

On Fri, Aug 14, 2015 at 12:14 PM, Goswin von Brederlow
<goswin-v-b@xxxxxx> 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):

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at