Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2610554pxb; Sun, 17 Oct 2021 20:25:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+jY4/I09M3UPeH56whLjyCa6Cav4vWJ/CMOEWyUSSIbqCWFyHEl16UjiGnA7l8guk09Lp X-Received: by 2002:a63:954a:: with SMTP id t10mr14691042pgn.89.1634527559342; Sun, 17 Oct 2021 20:25:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634527559; cv=none; d=google.com; s=arc-20160816; b=r513Q2MW5Z4DdRuKT7uyXgxlmeeFhc8aHpHLlJg0mEYWoe209jkQKvi6AeODQ+L/f2 DH5/Uwopqn+6+0R+w3SWjqJ1jPED1+H+MwkeiYYKL0nvsz64U31F+U5P12y3Wg5lPJCt CNfAtmSwP+Lytys2QSewgrCUoCO8iSExuOJwXvvh6DIVgWkQQv22ECbnU0pczZ4U56L5 0dC+kfK93QuaQEO7FZzFqz3Siw302FkxKc6nLpeGPGNzt85ksWbuvk4tTdpu6wA84Wli voS/pdAqLjVMrCt9slzRH6URRCFcVDRBWoOIM1OmIyJO/wGCpS8RND9NpRCQCE9hXrkH zafg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=bJ4g3ZKnmvunJdi+ctLSl5Yeyu3gse79YN5zl1xBHRQ=; b=Fg+EWUjw7Fz8qQCjz0PeNMcMnHQN3JOlk3n9WjUkYqroW4F/huavAf31xaKpHKCqCZ Q8W5OiMnh3EXHO89hfBxfOL1yDg1bXv4gzohPOi95sLW9kRsnbUgdFlhCorNfTDGKaG0 sLjiA12h+0x5BQVwnXP6OYCWK9VTfZqYBvjJil8FAcjmUjczzVw64nIPyE+5UkD4yoGQ 6F6tlKYapbThx3v7CQou5ESOnONW9tDpDoa7soDJRUFDNPx6ficUcAHw788EfIvfJ+2p OB8jbzbTQ8rod1MI6ztcuaRwemIJ2OtzYP3ZgxrJ4RXnScje7zAYAIT2DBRWgptpwSyH abvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=NsYEZQVN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d17si16634236pgj.581.2021.10.17.20.25.47; Sun, 17 Oct 2021 20:25:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=NsYEZQVN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239462AbhJPCvG (ORCPT + 98 others); Fri, 15 Oct 2021 22:51:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236923AbhJPCvF (ORCPT ); Fri, 15 Oct 2021 22:51:05 -0400 Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 899CCC061570; Fri, 15 Oct 2021 19:48:58 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id w12-20020a056830410c00b0054e7ceecd88so96590ott.2; Fri, 15 Oct 2021 19:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bJ4g3ZKnmvunJdi+ctLSl5Yeyu3gse79YN5zl1xBHRQ=; b=NsYEZQVNGVb+SrQVl+z43EzawS3aYeq38cjLN6UrUEykrUpxjLwLMvwt3Fz8rvRKE0 93vHS4KjQavA/ShpX8W9rApnzzr56kzcONhr/MeucFn3ccxsOU+RpigH1ONC8WWu4Y0I Mq3n4A4QBpFiJjft6rE3qgeK73Ohka+nb0dkxxZVc+6QV0Xg4stYpzjUkgKih/5I1p2R ix5wRx68pwW8ZN3QZo8KxlIGC9AVaWEeaPoDoo8+U/LpYIeAQowUo5IzgtnMyOwbPxSa WTf/vNCRJPHTenI6m++UwwmMXRSkims5F40oKG4/jVqkrIjBYRHnmN59saxBWjdBE9W1 uUCg== 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=bJ4g3ZKnmvunJdi+ctLSl5Yeyu3gse79YN5zl1xBHRQ=; b=WQw3RYpZ/EiWQhJD7ZGp96Im925lHoSUa6OMIH9Kju4Ju9g0P+R+A7YQ3M/TFLec2D Z8GFBBJOLA4ckiVJnZ0/1mtrGgi7A4z9IPD+enisvPxLIxze5yeU5i6c6j0i0HN6vAM1 +H1Md3JDM2kG47B96iDmIrpxRUVsOS4+1YtCppaT2E3zKRMHZ3v6s1in5VWjct2LfHWz Y0Y6TU6coCdRHsRglu5Hxo9vAdghqHT88l+GbmqL8++k5EEzP96fYPrrfOV2zGS64Tjf WgZ9IGTnqJr3tWO7Gz0Zu0E0f74QmP6nV8vxKhZkBCsgEvsiUEJyAfQ/tvo0p8i+PAxA nIuw== X-Gm-Message-State: AOAM533RzIEjuHWZpinanIk244hsBm0C8ZIlS50ojMVh6dEAwjAHA01i V63AUsPVYSv2epCrGUmnI3phkhjhfHGnGX8cFUU= X-Received: by 2002:a9d:17cd:: with SMTP id j71mr11380632otj.169.1634352537921; Fri, 15 Oct 2021 19:48:57 -0700 (PDT) MIME-Version: 1.0 References: <1633770532-23664-1-git-send-email-wanpengli@tencent.com> <1633770532-23664-3-git-send-email-wanpengli@tencent.com> In-Reply-To: From: Wanpeng Li Date: Sat, 16 Oct 2021 10:48:46 +0800 Message-ID: Subject: Re: [PATCH v2 3/3] KVM: vCPU kick tax cut for running vCPU To: Sean Christopherson Cc: LKML , kvm , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 16 Oct 2021 at 07:26, Sean Christopherson wrote: > > On Sat, Oct 09, 2021, Wanpeng Li wrote: > > From: Wanpeng Li > > > > Sometimes a vCPU kick is following a pending request, even if @vcpu is > > the running vCPU. It suffers from both rcuwait_wake_up() which has > > rcu/memory barrier operations and cmpxchg(). Let's check vcpu->wait > > before rcu_wait_wake_up() and whether @vcpu is the running vCPU before > > cmpxchg() to tax cut this overhead. > > > > We evaluate the kvm-unit-test/vmexit.flat on an Intel ICX box, most of the > > scores can improve ~600 cpu cycles especially when APICv is disabled. > > > > tscdeadline_immed > > tscdeadline > > self_ipi_sti_nop > > .............. > > x2apic_self_ipi_tpr_sti_hlt > > > > Suggested-by: Sean Christopherson > > Signed-off-by: Wanpeng Li > > --- > > v1 -> v2: > > * move checking running vCPU logic to kvm_vcpu_kick > > * check rcuwait_active(&vcpu->wait) etc > > > > virt/kvm/kvm_main.c | 13 ++++++++++--- > > 1 file changed, 10 insertions(+), 3 deletions(-) > > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 7851f3a1b5f7..18209d7b3711 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -3314,8 +3314,15 @@ void kvm_vcpu_kick(struct kvm_vcpu *vcpu) > > { > > int me, cpu; > > > > - if (kvm_vcpu_wake_up(vcpu)) > > - return; > > + me = get_cpu(); > > + > > + if (rcuwait_active(&vcpu->wait) && kvm_vcpu_wake_up(vcpu)) > > This needs to use kvm_arch_vcpu_get_wait(), not vcpu->wait, because PPC has some > funky wait stuff. > > One potential issue I didn't think of before. rcuwait_active() comes with the > below warning, which means we might be at risk of a false negative that could > result in a missed wakeup. I'm not postive on that though. There is only ever a single waiting vCPU, an event will be requested before kick the sleeping vCPU and it will be checked after setting vcpu->wait to task. I can't find scenario could result in a missed wakeup. Wanpeng > > /* > * Note: this provides no serialization and, just as with waitqueues, > * requires care to estimate as to whether or not the wait is active. > */