From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09974C433E0 for ; Tue, 26 Jan 2021 08:20:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B8150230FF for ; Tue, 26 Jan 2021 08:20:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389793AbhAZIUN (ORCPT ); Tue, 26 Jan 2021 03:20:13 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:38490 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389773AbhAZIT0 (ORCPT ); Tue, 26 Jan 2021 03:19:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611649064; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kElVC+jkHLstLVhvoAPiIFDGEp54B3rvncUWM43dOQw=; b=KBkGZZsdoIqA7PXALB8KdTBmpejg8UIKzxhfAkhmkp2woAdj+xBPkgpHXQJ6YEi2M1wRIk GwwtOQfIvxzFCZROO4HDfhJn2YbFXl19eVbY9I9xmcTsLjY9u0vxlg5z4QgERAM05QRkFj hDmErT6UD22W2qJr04QiMjNqZLmy01U= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-140-kXrSMgh9PS6y4-sMWhagKQ-1; Tue, 26 Jan 2021 03:17:43 -0500 X-MC-Unique: kXrSMgh9PS6y4-sMWhagKQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 07CAD107ACF6; Tue, 26 Jan 2021 08:17:41 +0000 (UTC) Received: from [10.72.12.70] (ovpn-12-70.pek2.redhat.com [10.72.12.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id E668E1A839; Tue, 26 Jan 2021 08:17:29 +0000 (UTC) Subject: Re: [RFC v3 11/11] vduse: Introduce a workqueue for irq injection To: Xie Yongji , mst@redhat.com, stefanha@redhat.com, sgarzare@redhat.com, parav@nvidia.com, bob.liu@oracle.com, hch@infradead.org, rdunlap@infradead.org, willy@infradead.org, viro@zeniv.linux.org.uk, axboe@kernel.dk, bcrl@kvack.org, corbet@lwn.net Cc: virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, kvm@vger.kernel.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org References: <20210119045920.447-1-xieyongji@bytedance.com> <20210119050756.600-1-xieyongji@bytedance.com> <20210119050756.600-5-xieyongji@bytedance.com> From: Jason Wang Message-ID: <9cacd59d-1063-7a1f-9831-8728eb1d1c15@redhat.com> Date: Tue, 26 Jan 2021 16:17:28 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210119050756.600-5-xieyongji@bytedance.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2021/1/19 下午1:07, Xie Yongji wrote: > This patch introduces a dedicated workqueue for irq injection > so that we are able to do some performance tuning for it. > > Signed-off-by: Xie Yongji If we want the split like this. It might be better to: 1) implement a simple irq injection on the ioctl context in patch 8 2) add the dedicated workqueue injection in this patch Since my understanding is that 1) the function looks more isolated for readers 2) the difference between sysctl vs workqueue should be more obvious than system wq vs dedicated wq 3) a chance to describe why workqueue is needed in the commit log in this patch Thanks > --- > drivers/vdpa/vdpa_user/eventfd.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/vdpa/vdpa_user/eventfd.c b/drivers/vdpa/vdpa_user/eventfd.c > index dbffddb08908..caf7d8d68ac0 100644 > --- a/drivers/vdpa/vdpa_user/eventfd.c > +++ b/drivers/vdpa/vdpa_user/eventfd.c > @@ -18,6 +18,7 @@ > #include "eventfd.h" > > static struct workqueue_struct *vduse_irqfd_cleanup_wq; > +static struct workqueue_struct *vduse_irq_wq; > > static void vduse_virqfd_shutdown(struct work_struct *work) > { > @@ -57,7 +58,7 @@ static int vduse_virqfd_wakeup(wait_queue_entry_t *wait, unsigned int mode, > __poll_t flags = key_to_poll(key); > > if (flags & EPOLLIN) > - schedule_work(&virqfd->inject); > + queue_work(vduse_irq_wq, &virqfd->inject); > > if (flags & EPOLLHUP) { > spin_lock(&vq->irq_lock); > @@ -165,11 +166,18 @@ int vduse_virqfd_init(void) > if (!vduse_irqfd_cleanup_wq) > return -ENOMEM; > > + vduse_irq_wq = alloc_workqueue("vduse-irq", WQ_SYSFS | WQ_UNBOUND, 0); > + if (!vduse_irq_wq) { > + destroy_workqueue(vduse_irqfd_cleanup_wq); > + return -ENOMEM; > + } > + > return 0; > } > > void vduse_virqfd_exit(void) > { > + destroy_workqueue(vduse_irq_wq); > destroy_workqueue(vduse_irqfd_cleanup_wq); > } >