similar to: [PATCH] virtio-fs: Improved request latencies when Virtio queue is full

When the Virtio queue is full, a work item is scheduled to execute in 1ms that retries adding the request to the queue. This is a large amount of time on the scale on which a virtio-fs device can operate. When using a DPU this is around 40us baseline without going to a remote server (4k, QD=1). This patch queues requests when the Virtio queue is full, and when a completed request is taken off,

When the Virtio queue is full, a work item is scheduled to execute in 1ms that retries adding the request to the queue. This is a large amount of time on the scale on which a virtio-fs device can operate. When using a DPU this is around 40us baseline without going to a remote server (4k, QD=1). This patch queues requests when the Virtio queue is full, and when a completed request is taken off,

On Wed, May 31, 2023 at 10:34:15PM +0200, Peter-Jan Gootzen wrote: > On 31/05/2023 21:18, Vivek Goyal wrote: > > On Wed, May 31, 2023 at 07:10:32PM +0200, Peter-Jan Gootzen wrote: > >> When the Virtio queue is full, a work item is scheduled > >> to execute in 1ms that retries adding the request to the queue. > >> This is a large amount of time on the scale on

On Wed, May 31, 2023 at 04:49:39PM -0400, Vivek Goyal wrote: > On Wed, May 31, 2023 at 10:34:15PM +0200, Peter-Jan Gootzen wrote: > > On 31/05/2023 21:18, Vivek Goyal wrote: > > > On Wed, May 31, 2023 at 07:10:32PM +0200, Peter-Jan Gootzen wrote: > > >> When the Virtio queue is full, a work item is scheduled > > >> to execute in 1ms that retries adding the

On 01/06/2023 16:08, Stefan Hajnoczi wrote: > On Wed, May 31, 2023 at 04:49:39PM -0400, Vivek Goyal wrote: >> On Wed, May 31, 2023 at 10:34:15PM +0200, Peter-Jan Gootzen wrote: >>> On 31/05/2023 21:18, Vivek Goyal wrote: >>>> On Wed, May 31, 2023 at 07:10:32PM +0200, Peter-Jan Gootzen wrote: >>>>> When the Virtio queue is full, a work item is scheduled

Currently we are duplicating logic to send forgets at two places. Consolidate the code by calling one helper function. This also uses virtqueue_add_outbuf() instead of virtqueue_add_sgs(). Former is simpler to call. Signed-off-by: Vivek Goyal <vgoyal at redhat.com> --- fs/fuse/virtio_fs.c | 150 +++++++++++++++++++------------------------- 1 file changed, 63 insertions(+), 87 deletions(-)

If virtqueue is full, we put forget requests on a list and these forgets are dispatched later using a worker. As of now we don't count these forgets in fsvq->in_flight variable. This means when queue is being drained, we have to have special logic to first drain these pending requests and then wait for fsvq->in_flight to go to zero. By counting pending forgets in fsvq->in_flight, we

On Tue, Sep 03, 2019 at 01:42:02PM +0200, Miklos Szeredi wrote: > From: Stefan Hajnoczi <stefanha at redhat.com> > > Add a basic file system module for virtio-fs. This does not yet contain > shared data support between host and guest or metadata coherency speedups. > However it is already significantly faster than virtio-9p. > > Design Overview > ===============

On Tue, Sep 03, 2019 at 01:42:02PM +0200, Miklos Szeredi wrote: > From: Stefan Hajnoczi <stefanha at redhat.com> > > Add a basic file system module for virtio-fs. This does not yet contain > shared data support between host and guest or metadata coherency speedups. > However it is already significantly faster than virtio-9p. > > Design Overview > ===============

On Thu, Sep 05, 2019 at 03:15:15PM -0400, Vivek Goyal wrote: > On Tue, Sep 03, 2019 at 09:55:49AM -0400, Michael S. Tsirkin wrote: > [..] > > What's with all of the TODOs? Some of these are really scary, > > looks like they need to be figured out before this is merged. > > Hi Michael, > > One of the issue I noticed is races w.r.t device removal and super >

Hi, We have couple of places which can result in deadlock. This patch series fixes these. We can be called with fc->bg_lock (for background requests) while submitting a request. This leads to two constraints. - We can't end requests in submitter's context and call fuse_end_request() as it tries to take fc->bg_lock as well. So queue these requests on a list and use a worker to

Hi Miklos, Here are few small cleanups for virtiofs for 5.5. I had received some comments from Michael Tsirkin on original virtiofs patches and these cleanups are result of these comments. Thanks Vivek Vivek Goyal (3): virtiofs: Use a common function to send forget virtiofs: Do not send forget request "struct list_head" element virtiofs: Use completions while waiting for queue

While we wait for queue to finish draining, use completions instead of uslee_range(). This is better way of waiting for event. Signed-off-by: Vivek Goyal <vgoyal at redhat.com> --- fs/fuse/virtio_fs.c | 39 +++++++++++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index 43224db8d9ed..b5ba83ef1914 100644

On Thu, Sep 12, 2019 at 04:19:31PM +0200, Miklos Szeredi wrote: > From: Stefan Hajnoczi <stefanha at redhat.com> > > Michael, > > Here's a v6 of the virtiofs code (fuse.git#virtiofs-v6). I think we've > addressed all your comments. > > Would you mind giving it another look, and if you're satisfied acking this > patch? > > Thanks, > Miklos

On Tue, Sep 03, 2019 at 09:55:49AM -0400, Michael S. Tsirkin wrote: [..] > What's with all of the TODOs? Some of these are really scary, > looks like they need to be figured out before this is merged. Hi Michael, One of the issue I noticed is races w.r.t device removal and super block initialization. I am about to post a set of patches which take care of these races and also get rid of

When device is going away, drain all pending requests. Signed-off-by: Vivek Goyal <vgoyal at redhat.com> --- fs/fuse/virtio_fs.c | 83 ++++++++++++++++++++++++++++----------------- 1 file changed, 51 insertions(+), 32 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index 90e7b2f345e5..d5730a50b303 100644 --- a/fs/fuse/virtio_fs.c +++ b/fs/fuse/virtio_fs.c @@ -63,6

On Mon, Oct 21, 2019 at 10:03:39AM +0200, Miklos Szeredi wrote: [..] > > static void virtio_fs_hiprio_dispatch_work(struct work_struct *work) > > @@ -502,6 +522,7 @@ static int virtio_fs_setup_vqs(struct virtio_device *vdev, > > names[VQ_HIPRIO] = fs->vqs[VQ_HIPRIO].name; > > INIT_WORK(&fs->vqs[VQ_HIPRIO].done_work, virtio_fs_hiprio_done_work);

On Mon, Oct 21, 2019 at 10:15:18AM +0200, Miklos Szeredi wrote: [..] > > @@ -268,13 +272,43 @@ static void virtio_fs_request_dispatch_work(struct work_struct *work) > > list); > > if (!req) { > > spin_unlock(&fsvq->lock); > > - return; > > +

Hi, Michael Tsirkin pointed out issues w.r.t various locking related TODO items and races w.r.t device removal. In this first round of cleanups, I have taken care of most pressing issues. These patches apply on top of following. git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v4 I have tested these patches with mount/umount and device removal using qemu monitor. For

During virtio_kill_sb() we first stop forget queue and drain it and then call fuse_kill_sb_anon(). This will result in sending DESTROY request to fuse server. Once finished, stop all the queues and drain one more time just to be sure and then free up the devices. Given drain queues will call flush_work() on various workers, remove this logic from virtio_free_devs(). Signed-off-by: Vivek Goyal