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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE0E4C433F5 for ; Tue, 16 Nov 2021 05:01:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9792661BFA for ; Tue, 16 Nov 2021 05:01:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237206AbhKPFEi (ORCPT ); Tue, 16 Nov 2021 00:04:38 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:38160 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237191AbhKPFEK (ORCPT ); Tue, 16 Nov 2021 00:04:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637038865; 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: in-reply-to:in-reply-to:references:references; bh=NZbJVFSsiYxk6JEYO0Xpu55G92qAXMwmH+tm+8XpReU=; b=NB6hh+FGiPwku2/wiMi9NwyVVAOUiF0fgCnPHoVcYd5m58moRIvgAwxc3353c1JTRFTtyF GraPW4LObSO39nkBALnG0bs40jyU4YxWJ+cxIh1e2UyhZ+wwVHT1nwQU9Y1Qw2C6Xf11Je 7afVPm3/KXbo+7bUD0pByy6wy9EpsGo= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-103-MStrXWspOz29i_y5STOCIA-1; Tue, 16 Nov 2021 00:01:02 -0500 X-MC-Unique: MStrXWspOz29i_y5STOCIA-1 Received: by mail-lf1-f70.google.com with SMTP id s18-20020ac25c52000000b004016bab6a12so7754872lfp.21 for ; Mon, 15 Nov 2021 21:01:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NZbJVFSsiYxk6JEYO0Xpu55G92qAXMwmH+tm+8XpReU=; b=m8z4LTqyWtn5gNyKdSw5aXTIKhohGSSOPNflVR+WSSDziFji7WJ9T+SKnE8ug2tTfy LQrFL4UySrEjRfIHL656CC4LX/EiVk1ctDJD9puXfRK41299NmwXo0tGQX3fq/cozepo 1pD4wWeatsEGUEOYGbrtWsmdAzjORQsllmGXmAjIE66/aMMmOkzqch/pint9J5LFoD3H wpsddzc7h7e+HO1LE9q/Kgld2zCBLbLEMHXSx4B9MyAUwoPfZJ9+5A0PbyC27a7G08/Q lUZVlaXGDJJ/pt1azSgQA2xmuq0uglFmJivlFwXhGTY/d6SBmiTunqUMYmSxYO/xF7uf wh2A== X-Gm-Message-State: AOAM532nAVtgixW09OMuvJrhHwvqpz4Y7bG/q8Rp3enQJ086Gd3THgmD ctYKA2/zSeyxVX+4mplSQ8T3ArrWuRPhv81JgA4x/LYGMaijcrQlbtxeka1FaZXplqxhicATR5G LgKDv2DDGdvyewRGfE/nLCuPovHNS X-Received: by 2002:ac2:518b:: with SMTP id u11mr3980747lfi.498.1637038861020; Mon, 15 Nov 2021 21:01:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJwmwi8ZBJDwkdhthf+6U7z0+K409Zl2U1G1z4cKoLh4WJGn9JeAOqnszcmQh+p5V5nQXwNj+ySZvlSCNDXcV2U= X-Received: by 2002:ac2:518b:: with SMTP id u11mr3980732lfi.498.1637038860836; Mon, 15 Nov 2021 21:01:00 -0800 (PST) MIME-Version: 1.0 References: <20211115153003.9140-1-arbn@yandex-team.com> <20211115153003.9140-6-arbn@yandex-team.com> In-Reply-To: <20211115153003.9140-6-arbn@yandex-team.com> From: Jason Wang Date: Tue, 16 Nov 2021 13:00:50 +0800 Message-ID: Subject: Re: [PATCH 6/6] vhost_net: use RCU callbacks instead of synchronize_rcu() To: Andrey Ryabinin Cc: "Michael S. Tsirkin" , Stefan Hajnoczi , Stefano Garzarella , Alexei Starovoitov , Daniel Borkmann , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , John Fastabend , kvm , virtualization , netdev , linux-kernel , bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Nov 15, 2021 at 11:32 PM Andrey Ryabinin wrote: > > Currently vhost_net_release() uses synchronize_rcu() to synchronize > freeing with vhost_zerocopy_callback(). However synchronize_rcu() > is quite costly operation. It take more than 10 seconds > to shutdown qemu launched with couple net devices like this: > -netdev tap,id=tap0,..,vhost=on,queues=80 > because we end up calling synchronize_rcu() netdev_count*queues times. > > Free vhost net structures in rcu callback instead of using > synchronize_rcu() to fix the problem. I admit the release code is somehow hard to understand. But I wonder if the following case can still happen with this: CPU 0 (vhost_dev_cleanup) CPU1 (vhost_net_zerocopy_callback()->vhost_work_queue()) if (!dev->worker) dev->worker = NULL wake_up_process(dev->worker) If this is true. It seems the fix is to move RCU synchronization stuff in vhost_net_ubuf_put_and_wait()? Thanks > > Signed-off-by: Andrey Ryabinin > --- > drivers/vhost/net.c | 22 ++++++++++++++-------- > 1 file changed, 14 insertions(+), 8 deletions(-) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 97a209d6a527..0699d30e83d5 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -132,6 +132,7 @@ struct vhost_net { > struct vhost_dev dev; > struct vhost_net_virtqueue vqs[VHOST_NET_VQ_MAX]; > struct vhost_poll poll[VHOST_NET_VQ_MAX]; > + struct rcu_head rcu; > /* Number of TX recently submitted. > * Protected by tx vq lock. */ > unsigned tx_packets; > @@ -1389,6 +1390,18 @@ static void vhost_net_flush(struct vhost_net *n) > } > } > > +static void vhost_net_free(struct rcu_head *rcu_head) > +{ > + struct vhost_net *n = container_of(rcu_head, struct vhost_net, rcu); > + > + kfree(n->vqs[VHOST_NET_VQ_RX].rxq.queue); > + kfree(n->vqs[VHOST_NET_VQ_TX].xdp); > + kfree(n->dev.vqs); > + if (n->page_frag.page) > + __page_frag_cache_drain(n->page_frag.page, n->refcnt_bias); > + kvfree(n); > +} > + > static int vhost_net_release(struct inode *inode, struct file *f) > { > struct vhost_net *n = f->private_data; > @@ -1404,15 +1417,8 @@ static int vhost_net_release(struct inode *inode, struct file *f) > sockfd_put(tx_sock); > if (rx_sock) > sockfd_put(rx_sock); > - /* Make sure no callbacks are outstanding */ > - synchronize_rcu(); > > - kfree(n->vqs[VHOST_NET_VQ_RX].rxq.queue); > - kfree(n->vqs[VHOST_NET_VQ_TX].xdp); > - kfree(n->dev.vqs); > - if (n->page_frag.page) > - __page_frag_cache_drain(n->page_frag.page, n->refcnt_bias); > - kvfree(n); > + call_rcu(&n->rcu, vhost_net_free); > return 0; > } > > -- > 2.32.0 >