From mboxrd@z Thu Jan 1 00:00:00 1970 From: Liang Chen Subject: Re: [PATCH v2] KVM: x86: count actual tlb flushes Date: Thu, 18 Sep 2014 10:47:36 -0400 Message-ID: <541AF088.20101@gmail.com> References: <1410978955-19003-1-git-send-email-liangchen.linux@gmail.com> <20140918140011.GB16538@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: pbonzini@redhat.com, kvm@vger.kernel.org To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from mail-qa0-f46.google.com ([209.85.216.46]:32865 "EHLO mail-qa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755653AbaIROrf (ORCPT ); Thu, 18 Sep 2014 10:47:35 -0400 Received: by mail-qa0-f46.google.com with SMTP id f12so1189621qad.19 for ; Thu, 18 Sep 2014 07:47:34 -0700 (PDT) In-Reply-To: <20140918140011.GB16538@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/18/2014 10:00 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 2014-09-17 14:35-0400, Liang Chen: >> - we count KVM_REQ_TLB_FLUSH requests, not actual flushes >> (KVM can have multiple requests for one flush) >> - flushes from kvm_flush_remote_tlbs aren't counted >> - it's easy to make a direct request by mistake >> >> Solve these by postponing the counting to kvm_check_request(), >> and refactor the code to use kvm_make_request again. >> >> Signed-off-by: Liang Chen >> --- >> Changes since v2: >> >> * Instead of calling kvm_mmu_flush_tlb everywhere to make sure the >> stat is always incremented, postponing the counting to >> kvm_check_request. >> >> (The idea comes from Radim. Much of the work is indeed done by him >> and is included in this patch, otherwise I couldn't start working >> on the followup work as I promised early. As I'm new to kvm >> development, please let me know if I am doing wrong here.) > I found (shame on me) Documentation/development-process/ when looking > how to help and it looks really good. > (If you read it, the rest of my mail will be obsolete :) > > You usually want to Cc linux-kernel@vger.kernel.org. > (I've heard that someone actually reads it directly and it is a good > archive otherwise. It allows people to `git blame` your code and fi= nd > the discussion in their preferred mail reader.) > > The hard part about posting a patch is splitting it ... > You want to separate logical changes to make the code maintainable: > For this patch, I would create at least two-part series (cover letter= !) > > - change the meaning of tlb_flush > - refactor code > > And see if it would make sense to split the refactoring further or if= it > breaks when only a first part of the whole series is applied. > > It's not a problem if your code depends on unmerged patches, you can > include someone else's code in the series as long as it isn't modifie= d. > (Which probably is better than just mentioning that your code depends= on > some other patches from the list, but I'm not applying it ... Paolo?= ) Thank you very much for the help! Creating a patch series and including your patch intact as the first one sound to be the best ;) Thanks, Liang