On 09/18/2014 10:00 AM, Radim Krčmář 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 <liangchen.linux@xxxxxxxxx> >> --- >> 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@xxxxxxxxxxxxxxx. > (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 find > 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 modified. > (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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
