Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1668979pxj; Wed, 19 May 2021 11:03:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJze2hUR/PURj1ev1EHETan7Uy6rgVdzguPBpVnjCr15Jg9MmR9VUVIX1g7+rpgdaj8xRq0E X-Received: by 2002:a50:afa3:: with SMTP id h32mr316863edd.202.1621447427787; Wed, 19 May 2021 11:03:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621447427; cv=none; d=google.com; s=arc-20160816; b=JbRUu4hPdd6pow76yIFOtRPhZWisGDQFn3Rhv6yrg/xaAqstcSNcmIAIOpWtrfIK+2 76STlsHlUCyOrgLM/ZgeJUVxXsTrecnJ6wA3oev5M2mhO1VYurBF1+h0q+4s4OltNlys 7t9ovTWPbvPQSs4akwAmhyvM4RPdvXW8mAZCC5hDycwreZeR3eFrHHh5ZPd4d3lemGfW KZX9QXHyxRmJ6vyrf+ZtbQmhO7UEiF0GiBY+vkgQR3e44vsJoYcu+jRT1bNZe4dFzYrD X9yQZzp+nuVbGW3CufdnPwwt2w5t+mS/WOAFthOlXd0LRT9AdsnyvFutaet0+q+tk6R/ nzJA== 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=hnEkWdOm+ENMVf7yX2CMz4AbmpChSKu1dSZbsT4Oixw=; b=LTtsFkg40L3BiOJsCx+VZPBDXt0k3+YjmGwh51QzvLJEF/JcBgJNxP0fWxunJ2Vnf+ wXsOlnnGWstdh4Vui/xH5D9fM5WbOlMl+Hx0v/wIMl8meeqEGQ5TR6I6KcE9r0ISkw+e ajcKWg1QbebhXMwoba1gKCFntYRugjR8Q9Sp5fmApTaaKXvsiLJYd4wWax/SITSVfWcZ M30nLGzUJ1VVk6k7D+ombmxwnZgbVqUp0A/MPjAZeUzww0sKjwLck/MvcTsCydh7jpsg SBCmr47Qgi9sFXGmGDS7PNRXlsKRrj0tykeyXwPHOu6hguQIlww/XvdunE5NWFwjsSm1 3xOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fA10Mkga; 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 x18si286885eji.715.2021.05.19.11.03.17; Wed, 19 May 2021 11:03:47 -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=20161025 header.b=fA10Mkga; 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 S245460AbhERMF1 (ORCPT + 99 others); Tue, 18 May 2021 08:05:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244853AbhERMFV (ORCPT ); Tue, 18 May 2021 08:05:21 -0400 Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBE3DC061756; Tue, 18 May 2021 05:04:03 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id s5-20020a05683004c5b029032307304915so1119253otd.7; Tue, 18 May 2021 05:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hnEkWdOm+ENMVf7yX2CMz4AbmpChSKu1dSZbsT4Oixw=; b=fA10MkgaqDEVhjoHM2C49i5DiSk8QAv4S6KmSm+TWymGUNEmMNwlQWgVBOL+FX5xNJ jBMhtpWp2zR7jsRBbqdKIlYPrkI3GHhwKNET3JTmsE77g6Nq3xdwTNXQwlpNyCzVfwGI 8bBel7+0EimQUk0jK0YdphDaRqwBErksDkKo3YQJoXqrz+KvXSwJldlfcYMVMkJVcrDs Neyw/FG6h991r91f4QDnNev86TDyIW/OlVorhwyDbCo4pdVaD3JF75bicZJYqVVgoxlP jixurboqH+jmKiWNvEl4c5AVp9GS6343Id+BXrWYIgUofhRFfEyXDzIL0BYd/LY3kXiX Fozg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hnEkWdOm+ENMVf7yX2CMz4AbmpChSKu1dSZbsT4Oixw=; b=WUME1Te3JKHh+tV5ER9dUulckhFvycapsnsqOHO9Sl8iYsgEvHcVZPG2C7/CORkJLD 0W6XGQdDQoPjI7pHs9MyfOO82oq1yargpDcGHQFMMPWggML2aQwRyBrOKe9/romt8iwL FQ+i42vUQr+n1ZAN/w58ArRjJJkOPkScwbUB60QaxCJf42u8UAm37lzU5WTAtRSEW/wb 7j35epn2GcRZbHXmaNSyyVwDSBze2qnEoeouVV2gD8uZ26+4mo4aQKcmE5aClaLEF5Rg 7TsFawLQVUgLHLMEJpmrF/3mW7pADGKMwVMtL1YPfJ94FpDrBlPpE8txG31fGHgUxod/ momg== X-Gm-Message-State: AOAM532pph1ckAK8OjF7+DHDj1fWYwDC1DBH86ZWxg+B1x8nGYUfko+k a+jmCLgg0i5uQy/FzvD3cX/81hO7b0irCsco7kQ= X-Received: by 2002:a9d:2966:: with SMTP id d93mr4007167otb.56.1621339443306; Tue, 18 May 2021 05:04:03 -0700 (PDT) MIME-Version: 1.0 References: <1621260028-6467-1-git-send-email-wanpengli@tencent.com> <1621260028-6467-5-git-send-email-wanpengli@tencent.com> In-Reply-To: From: Wanpeng Li Date: Tue, 18 May 2021 20:03:52 +0800 Message-ID: Subject: Re: [PATCH v3 5/5] KVM: LAPIC: Narrow the timer latency between wait_lapic_expire and world switch 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 Tue, 18 May 2021 at 01:51, Sean Christopherson wrote: > > On Mon, May 17, 2021, Wanpeng Li wrote: > > From: Wanpeng Li > > > > Let's treat lapic_timer_advance_ns automatically tune logic as hypervisor > > overhead, move it before wait_lapic_expire instead of between wait_lapic_expire > > and the world switch, the wait duration should be calculated by the > > up-to-date guest_tsc after the overhead of automatically tune logic. This > > patch reduces ~30+ cycles for kvm-unit-tests/tscdeadline-latency when testing > > busy waits. > > > > Signed-off-by: Wanpeng Li > > --- > > arch/x86/kvm/lapic.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > index c0ebef560bd1..552d2acf89ab 100644 > > --- a/arch/x86/kvm/lapic.c > > +++ b/arch/x86/kvm/lapic.c > > @@ -1598,11 +1598,12 @@ static void __kvm_wait_lapic_expire(struct kvm_vcpu *vcpu) > > guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()); > > apic->lapic_timer.advance_expire_delta = guest_tsc - tsc_deadline; > > > > - if (guest_tsc < tsc_deadline) > > - __wait_lapic_expire(vcpu, tsc_deadline - guest_tsc); > > - > > if (lapic_timer_advance_dynamic) > > adjust_lapic_timer_advance(vcpu, apic->lapic_timer.advance_expire_delta); > > + > > + guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()); > > This is redundant and unnecessary if automatic tuning is disabled, or if the > timer did not arrive early. A comment would also be helpful. E.g. I think this > would micro-optimize all paths: Do it in v4, thanks. Wanpeng > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > index c0ebef560bd1..5d91f2367c31 100644 > --- a/arch/x86/kvm/lapic.c > +++ b/arch/x86/kvm/lapic.c > @@ -1598,11 +1598,19 @@ static void __kvm_wait_lapic_expire(struct kvm_vcpu *vcpu) > guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()); > apic->lapic_timer.advance_expire_delta = guest_tsc - tsc_deadline; > > + if (lapic_timer_advance_dynamic) { > + adjust_lapic_timer_advance(vcpu, apic->lapic_timer.advance_expire_delta); > + /* > + * If the timer fired early, reread the TSC to account for the > + * overhead of the above adjustment to avoid waiting longer > + * than is necessary. > + */ > + if (guest_tsc < tsc_deadline) > + guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()); > + } > + > if (guest_tsc < tsc_deadline) > __wait_lapic_expire(vcpu, tsc_deadline - guest_tsc); > - > - if (lapic_timer_advance_dynamic) > - adjust_lapic_timer_advance(vcpu, apic->lapic_timer.advance_expire_delta); > } > > void kvm_wait_lapic_expire(struct kvm_vcpu *vcpu) > > > + if (guest_tsc < tsc_deadline) > > + __wait_lapic_expire(vcpu, tsc_deadline - guest_tsc); > > } > > > > void kvm_wait_lapic_expire(struct kvm_vcpu *vcpu) > > -- > > 2.25.1 > >