Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp6028830ybv; Tue, 18 Feb 2020 08:30:15 -0800 (PST) X-Google-Smtp-Source: APXvYqxyANJwwQmDGfz+GBnoQYgdmncDEmHe8U+jnel2Iou+Y+hEQz4uT2d0jD9naZHVh4bBDwo7 X-Received: by 2002:a9d:470a:: with SMTP id a10mr16860811otf.370.1582043415012; Tue, 18 Feb 2020 08:30:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582043415; cv=none; d=google.com; s=arc-20160816; b=UfyfUgkR7pauN69vsTfu3dMaD6jm65YjQ2hhQ6HvcNuBxHc0qiNYEo1e58Bk98CDyA Vqt8vZMrkan7NDOcaVH+qI2GbxD0u718t5R+8iGJxaYpic+0jZ4d8Ske6m2b+tXzVsCV E9gBIdqp4wS8XWd6tddCF/WosnGrzxkZkpPxsUwnsxOTwbbbwNoa4ofz5L+XjNVjOBZp ebOBxSsBqoygNaNcU1ZDf1MQbquVS3IDzI9CWNzrRvJA5U0m7rjeNC+5JFq/LxAPbvXj ATfplhttQV7sRwk03F9l/q0CmbsjTFmEZXS6hll53bo14PMn2gcnDEC2UTvvEGWUkinS Et8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=/xeFn2xogkvVTbJnDqLCWor5PNlBtKum0AFBL80A1+Q=; b=zwNernysWhU0TeAaifgW0a3Bj92LfxrEaGVdEV5bvWnF6gNHJR5v8qJslWzyts2NA9 ewQHFs8feDix8SUfEXKiS0H+GqgHfr8vZBawOYpQhKde1q+lFWzu+wid9zJnsdjd+YYB GHOu/dL1c4ABlF2C+wrsYTBeBuS7cD3SYvJD61u29wscJBASY2YLLMa5VBSYxH3IkJGB Ggslfc1wpY//5/S61oDZigTCpM/95KQoSUDwIZ3fAEGr2Hb8jFuhRTRiuT20Mjraf8h1 eiPXzbuvMO9EKOjN+SatHfozJHJGOuGfDiKbAvCFtW2yayxagBQ0FKEEpoA1qDcjZ+St 5GQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cO47Is+h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p19si1905852otk.251.2020.02.18.08.30.02; Tue, 18 Feb 2020 08:30:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cO47Is+h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726663AbgBRQ3v (ORCPT + 99 others); Tue, 18 Feb 2020 11:29:51 -0500 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:59079 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726422AbgBRQ3u (ORCPT ); Tue, 18 Feb 2020 11:29:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582043389; 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=/xeFn2xogkvVTbJnDqLCWor5PNlBtKum0AFBL80A1+Q=; b=cO47Is+hcCu1c5DYa7K1krdGrOf7LOS1FBQO5Pr4XDINCZ3kcT/6gxr5tufh+k4Rm3HEEN HGjIcDiqo5ySDpQlNOwQNmbWOcjy12IB0o7e+AIxp9uSGn3EUvVLAa3RRMsT44e2rl6wgP EwYS8SbjS7m3LitfgGxon5qfxT03MIw= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-209-IHskR0TJPmenkVWzUSfg6g-1; Tue, 18 Feb 2020 11:29:47 -0500 X-MC-Unique: IHskR0TJPmenkVWzUSfg6g-1 Received: by mail-wm1-f71.google.com with SMTP id f207so262755wme.6 for ; Tue, 18 Feb 2020 08:29:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=/xeFn2xogkvVTbJnDqLCWor5PNlBtKum0AFBL80A1+Q=; b=IS/8psNJbILaW60bcDD8UizqPgT3Fmam+5NrtKDIjQiVrc6oa4OvqZIuN3KrleBH7R s8hTcZ0IhLQwwpmS1MZkxepl60V0F3X0dVfvSB8Q54EffhiNoiovGpFvbb49LP4B1XRv NL1L6On+LFi3gBSjfz5JjpMcXisLgiJ0/q3dsurMtO6wfRbxYCWFkO7DPt5R7H5k70HH nnebGQEoNmNS2NjLNiOkFe9xM6bUtOczMILIb4PzXt1ciAlWY+KApJta5x1DuHRpFo8S 4opLhUnCqlAA7ZXdEIH0PDXqAcsszBrr1UUyPxzqu2lA7WGWvbpuLIXa3s8OBXN9wGet nYDA== X-Gm-Message-State: APjAAAUf+OZvHTsrBaa0dSQgxVB56mYTbuTIuBrD7B+7MANQ348+iTvD im3UwzgCACFIZedvq5+8N7ke9HccGaQLtGbvMnKyOvbgioUpvPliWPD8eQ+Z407U8ulkUePoOQP 3JZyGxBCrwKLKWMiZ7L48AEOL X-Received: by 2002:a05:600c:21c5:: with SMTP id x5mr4126821wmj.72.1582043386465; Tue, 18 Feb 2020 08:29:46 -0800 (PST) X-Received: by 2002:a05:600c:21c5:: with SMTP id x5mr4126799wmj.72.1582043386211; Tue, 18 Feb 2020 08:29:46 -0800 (PST) Received: from vitty.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id x6sm4088344wmi.44.2020.02.18.08.29.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Feb 2020 08:29:45 -0800 (PST) From: Vitaly Kuznetsov To: Paolo Bonzini , Wanpeng Li Cc: Sean Christopherson , Wanpeng Li , Jim Mattson , Joerg Roedel , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v4 1/2] KVM: X86: Less kvmclock sync induced vmexits after VM boots In-Reply-To: References: <1581988630-19182-1-git-send-email-wanpengli@tencent.com> <87r1ys7xpk.fsf@vitty.brq.redhat.com> Date: Tue, 18 Feb 2020 17:29:44 +0100 Message-ID: <87mu9f97uv.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Paolo Bonzini writes: > On 18/02/20 15:54, Vitaly Kuznetsov wrote: >>> - schedule_delayed_work(&kvm->arch.kvmclock_sync_work, >>> - KVMCLOCK_SYNC_PERIOD); >>> + if (vcpu->vcpu_idx == 0) >>> + schedule_delayed_work(&kvm->arch.kvmclock_sync_work, >>> + KVMCLOCK_SYNC_PERIOD); >>> } >>> >>> void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu) >> Forgive me my ignorance, I was under the impression >> schedule_delayed_work() doesn't do anything if the work is already >> queued (see queue_delayed_work_on()) and we seem to be scheduling the >> same work (&kvm->arch.kvmclock_sync_work) which is per-kvm (not >> per-vcpu). > > No, it executes after 5 minutes. I agree that the patch shouldn't be > really necessary, though you do save on cacheline bouncing due to > test_and_set_bit. > True, but the changelog should probably be updated then. -- Vitaly