From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C95D9C5CFC1 for ; Tue, 19 Jun 2018 13:20:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B89520652 for ; Tue, 19 Jun 2018 13:20:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B89520652 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937865AbeFSNUF (ORCPT ); Tue, 19 Jun 2018 09:20:05 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59506 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S937616AbeFSNUE (ORCPT ); Tue, 19 Jun 2018 09:20:04 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 856E240201BE; Tue, 19 Jun 2018 13:20:03 +0000 (UTC) Received: from vitty.brq.redhat.com.redhat.com (unknown [10.43.2.155]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2B5082026D68; Tue, 19 Jun 2018 13:20:02 +0000 (UTC) From: Vitaly Kuznetsov To: Thomas Gleixner Cc: Stephen Hemminger , Tianyu Lan , Haiyang Zhang , x86@kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , "H. Peter Anvin" , devel@linuxdriverproject.org Subject: Re: [PATCH] x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST, SPACE} hypercalls when possible References: <20180615163010.20381-1-vkuznets@redhat.com> <87wouvkk5x.fsf@vitty.brq.redhat.com> Date: Tue, 19 Jun 2018 15:20:01 +0200 In-Reply-To: (Thomas Gleixner's message of "Tue, 19 Jun 2018 15:04:26 +0200 (CEST)") Message-ID: <87o9g6lxq6.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 19 Jun 2018 13:20:03 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 19 Jun 2018 13:20:03 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'vkuznets@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Gleixner writes: > On Tue, 19 Jun 2018, Vitaly Kuznetsov wrote: >> Thomas Gleixner writes: >> >> > On Fri, 15 Jun 2018, Vitaly Kuznetsov wrote: >> >> * Fills in gva_list starting from offset. Returns the number of items added. >> >> @@ -93,10 +95,19 @@ static void hyperv_flush_tlb_others(const struct cpumask *cpus, >> >> if (cpumask_equal(cpus, cpu_present_mask)) { >> >> flush->flags |= HV_FLUSH_ALL_PROCESSORS; >> >> } else { >> >> + /* >> >> + * It is highly likely that VP ids are in ascending order >> >> + * matching Linux CPU ids; Check VP index for the highest CPU >> >> + * in the supplied set to see if EX hypercall is required. >> >> + * This is just a best guess but should work most of the time. >> > >> > TLB flushing based on 'best guess' and 'should work most of the time' is >> > not a brilliant approach. >> > >> >> Oh no no no, that's not what I meant :-) >> >> We have the following problem: from the supplied CPU set we need to >> figure out if we can get away with HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST, >> SPACE} hypercalls which are cheaper or if we need to use more expensing >> HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST, SPACE}_EX ones. The dividing line is >> the highest VP_INDEX of the supplied CPU set: in case it is < 64 cheaper >> hypercalls are OK. Now how do we check that? In the patch I have the >> following approach: >> 1) Check VP number for the highest CPU in the supplied set. In case it >> is > 64 we for sure need more expensive hypercalls. This is the "guess" >> which works most of the time because Linux CPU ids usually match >> VP_INDEXes. >> >> 2) In case the answer to the previous question was negative we start >> preparing input for the cheaper hypercall. However, if while walking the >> CPU set we meet a CPU with VP_INDEX higher than 64 we'll discard the >> prepared input and switch to the more expensive hypercall. >> >> Said that the 'guess' here is just an optimization to avoid walking the >> whole CPU set when we find the required answer quickly by looking at the >> highest bit. This will help big systems with hundreds of CPUs. > > Care to fix the comment to avoid the offending words? > Sure, will re-word in v2. -- Vitaly