From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Cindy Lu <lulu@redhat.com>,
michael.christie@oracle.com, sgarzare@redhat.com,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org
Subject: Re: [PATCH v9 2/4] vhost: Reintroduce kthread mode support in vhost
Date: Mon, 21 Apr 2025 06:59:34 -0400 [thread overview]
Message-ID: <20250421065847-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEtCxn7rZfvo9_nUwC1TwqJ+5F2XDdU89rz=iyO3U0pCEQ@mail.gmail.com>
On Mon, Apr 21, 2025 at 11:39:14AM +0800, Jason Wang wrote:
> On Mon, Apr 21, 2025 at 10:45 AM Cindy Lu <lulu@redhat.com> wrote:
> >
> > This patch reintroduces kthread mode support in vhost,
> > It also introduces struct vhost_worker_ops to abstract
> > worker create/stop/wakeup operations.
> >
> > * Bring back the original vhost_worker() implementation,
> > and renamed to vhost_run_work_kthread_list().
> >
> > * Add cgroup support for the kthread
> >
> > * Introduce struct vhost_worker_ops:
> > - Encapsulates create / stop / wake‑up callbacks.
> > - vhost_worker_create() selects the proper ops according to
> > inherit_owner.
> >
> > This partially reverts or improves upon:
> > commit 6e890c5d5021 ("vhost: use vhost_tasks for worker threads")
> > commit 1cdaafa1b8b4 ("vhost: replace single worker pointer with xarray")
> >
> > Signed-off-by: Cindy Lu <lulu@redhat.com>
> > ---
> > drivers/vhost/vhost.c | 188 ++++++++++++++++++++++++++++++++++++++----
> > drivers/vhost/vhost.h | 12 +++
> > 2 files changed, 182 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 250dc43f1786..be97028a8baf 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -22,6 +22,7 @@
> > #include <linux/slab.h>
> > #include <linux/vmalloc.h>
> > #include <linux/kthread.h>
> > +#include <linux/cgroup.h>
> > #include <linux/module.h>
> > #include <linux/sort.h>
> > #include <linux/sched/mm.h>
> > @@ -242,7 +243,7 @@ static void vhost_worker_queue(struct vhost_worker *worker,
> > * test_and_set_bit() implies a memory barrier.
> > */
> > llist_add(&work->node, &worker->work_list);
> > - vhost_task_wake(worker->vtsk);
> > + worker->ops->wakeup(worker);
> > }
> > }
> >
> > @@ -388,6 +389,44 @@ static void vhost_vq_reset(struct vhost_dev *dev,
> > __vhost_vq_meta_reset(vq);
> > }
> >
> > +static int vhost_run_work_kthread_list(void *data)
> > +{
> > + struct vhost_worker *worker = data;
> > + struct vhost_work *work, *work_next;
> > + struct vhost_dev *dev = worker->dev;
> > + struct llist_node *node;
> > +
> > + kthread_use_mm(dev->mm);
> > +
> > + for (;;) {
> > + /* mb paired w/ kthread_stop */
> > + set_current_state(TASK_INTERRUPTIBLE);
> > +
> > + if (kthread_should_stop()) {
> > + __set_current_state(TASK_RUNNING);
> > + break;
> > + }
> > + node = llist_del_all(&worker->work_list);
> > + if (!node)
> > + schedule();
> > +
> > + node = llist_reverse_order(node);
> > + /* make sure flag is seen after deletion */
> > + smp_wmb();
> > + llist_for_each_entry_safe(work, work_next, node, node) {
> > + clear_bit(VHOST_WORK_QUEUED, &work->flags);
> > + __set_current_state(TASK_RUNNING);
> > + kcov_remote_start_common(worker->kcov_handle);
> > + work->fn(work);
> > + kcov_remote_stop();
> > + cond_resched();
> > + }
> > + }
> > + kthread_unuse_mm(dev->mm);
> > +
> > + return 0;
> > +}
> > +
> > static bool vhost_run_work_list(void *data)
> > {
> > struct vhost_worker *worker = data;
> > @@ -582,6 +621,46 @@ long vhost_dev_check_owner(struct vhost_dev *dev)
> > }
> > EXPORT_SYMBOL_GPL(vhost_dev_check_owner);
> >
> > +struct vhost_attach_cgroups_struct {
> > + struct vhost_work work;
> > + struct task_struct *owner;
> > + int ret;
> > +};
> > +
> > +static void vhost_attach_cgroups_work(struct vhost_work *work)
> > +{
> > + struct vhost_attach_cgroups_struct *s;
> > +
> > + s = container_of(work, struct vhost_attach_cgroups_struct, work);
> > + s->ret = cgroup_attach_task_all(s->owner, current);
> > +}
> > +
> > +static int vhost_attach_task_to_cgroups(struct vhost_worker *worker)
> > +{
> > + struct vhost_attach_cgroups_struct attach;
> > + int saved_cnt;
> > +
> > + attach.owner = current;
> > +
> > + vhost_work_init(&attach.work, vhost_attach_cgroups_work);
> > + vhost_worker_queue(worker, &attach.work);
> > +
> > + mutex_lock(&worker->mutex);
> > +
> > + /*
> > + * Bypass attachment_cnt check in __vhost_worker_flush:
> > + * Temporarily change it to INT_MAX to bypass the check
> > + */
> > + saved_cnt = worker->attachment_cnt;
> > + worker->attachment_cnt = INT_MAX;
> > + __vhost_worker_flush(worker);
> > + worker->attachment_cnt = saved_cnt;
>
> I wonder if it's easier to re-introduce the flush that was used before
> vhost kthread to avoid the tricks here. We can have flush ops for
> example.
>
> Thanks
Nah we do not need ops, __vhost_worker_flush is just an internal
function. Refactor it so we can call the part without the check.
--
MST
next prev parent reply other threads:[~2025-04-21 11:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-21 2:44 [PATCH v9 0/4] vhost: Add support of kthread API Cindy Lu
2025-04-21 2:44 ` [PATCH v9 1/4] vhost: Add a new parameter in vhost_dev to allow user select kthread Cindy Lu
2025-04-21 3:25 ` Jason Wang
2025-04-22 13:36 ` Stefano Garzarella
2025-04-21 2:44 ` [PATCH v9 2/4] vhost: Reintroduce kthread mode support in vhost Cindy Lu
2025-04-21 3:39 ` Jason Wang
2025-04-21 10:59 ` Michael S. Tsirkin [this message]
2025-04-21 10:58 ` Michael S. Tsirkin
2025-04-21 2:44 ` [PATCH v9 3/4] vhost: add VHOST_FORK_FROM_OWNER ioctl and validate inherit_owner Cindy Lu
2025-04-21 3:40 ` Jason Wang
2025-04-22 13:45 ` Stefano Garzarella
2025-04-21 2:44 ` [PATCH v9 4/4] vhost: Add a KConfig knob to enable IOCTL VHOST_FORK_FROM_OWNER Cindy Lu
2025-04-21 3:45 ` Jason Wang
2025-04-21 3:46 ` Jason Wang
2025-04-29 3:39 ` Jason Wang
2025-04-29 10:55 ` Michael S. Tsirkin
2025-04-30 3:34 ` Jason Wang
2025-04-30 9:27 ` Michael S. Tsirkin
2025-05-13 4:08 ` Jason Wang
2025-05-13 7:08 ` Michael S. Tsirkin
2025-05-14 2:52 ` Jason Wang
2025-05-15 6:05 ` Cindy Lu
2025-05-15 6:14 ` Michael S. Tsirkin
2025-05-16 1:31 ` Jason Wang
2025-05-16 10:39 ` Michael S. Tsirkin
2025-05-19 7:34 ` Jason Wang
2025-04-22 13:50 ` Stefano Garzarella
2025-04-23 1:01 ` Cindy Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250421065847-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=michael.christie@oracle.com \
--cc=netdev@vger.kernel.org \
--cc=sgarzare@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).