Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1231890 > unrolled thread

Re: [fuse-devel] fuse scalability part 1

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [fuse-devel] fuse scalability part 1 Miklos Szeredi <miklos@szeredi.hu> - 2015-09-24 08:40 +0200

#1231890 — Re: [fuse-devel] fuse scalability part 1

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web