Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp6192954imd; Wed, 31 Oct 2018 08:09:30 -0700 (PDT) X-Google-Smtp-Source: AJdET5dgYwvRwMD1zS5w62iidKeaWXPxR+i5N1p2Pl9XDVR8r2vLZCTGgraWe3vJSshYT02yhdVQ X-Received: by 2002:a17:902:aa8d:: with SMTP id d13-v6mr3901027plr.74.1540998570278; Wed, 31 Oct 2018 08:09:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540998570; cv=none; d=google.com; s=arc-20160816; b=d7Aeb2NyfICExUIg2RBCcLhRX6pMGIprOldyPkDPTplbBVUVxqC/8zNV8flMF+6ZHm kbl2h+NVVdjTNhCnKDmAPWqqKChwzq0MIKQFx6+qc7Qkw0cscPi3E7sekp5WKPG1AXLt tPzeLsZkGSg8GfLHNfKTAWyBzjBcrKU143uUTok98jdEI2sCemiwVzZsJUtaAV/IG2uL JXilLlZFrC1UWAsxSJYlRV0DbcSSILTCPLzTzLrPO3nwHyHNBGxDk6FxPkz/Di7vvXgK krsUCpmHnnmuVzNJ4yRk9Nu2S1WjiAcL4BUkx3mLeIqxWsbcE0SYT38iBiGl417GEvHK rPlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=wU1SXvQjR6/NMRrx3QjlZBx3MN7dMEgO0Rej7DXfhnw=; b=ywPcpzpblIaVKT3/J8HRjx2WSNO89qMaK5FifuMejjv6qI9iNGf+PQs7hw9jqYTfQ7 BMdF3nj5l1ri7lKm0jC4Y/vtT3NlSnQ4Qdzxkyh8C/t3d8HG1qwdcgnUmH/CZWnIgOCu sbX08jkboVN74qIg3/b3Ygdgx+Bx47v/C50uiXKY1HEwKsUFkqsmc1oHdBgwXxCtMYA0 02ZG3fJKVlWhmQdm2M2jZn6ofIpYIjVqgptgsOeGiE9dJtY2vDNTwBXN/oVJtd+htRge E/RHscj7W4heOrpU9OMElSU3IVYhzXN0mW2atTSmHnwp31MjNwWgtG0f5RvIU7OBILQ8 m+gA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 c22-v6si28097470pgb.472.2018.10.31.08.08.59; Wed, 31 Oct 2018 08:09:30 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729492AbeKAAFs convert rfc822-to-8bit (ORCPT + 99 others); Wed, 31 Oct 2018 20:05:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38114 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729445AbeKAAFs (ORCPT ); Wed, 31 Oct 2018 20:05:48 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 63FD181DFE; Wed, 31 Oct 2018 15:07:24 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-8.bos.redhat.com [10.18.17.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8B66F6107F; Wed, 31 Oct 2018 15:07:22 +0000 (UTC) Subject: Re: [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall To: Peter Zijlstra , Yi Sun Cc: Juergen Gross , linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de, chao.p.peng@intel.com, chao.gao@intel.com, isaku.yamahata@intel.com, michael.h.kelley@microsoft.com, tianyu.lan@microsoft.com, "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , "mingo@redhat.com" , Will Deacon References: <1539954835-34035-3-git-send-email-yi.y.sun@linux.intel.com> <20181022015342.GK11769@yi.y.sun> <2e0d62cb-b706-a5b4-65f7-982a913fb32b@suse.com> <20181022171516.GH3117@worktop.programming.kicks-ass.net> <20181023025740.GL11769@yi.y.sun> <20181023085127.GG3109@worktop.c.hoisthospitality.com> <20181023093328.GA15378@yi.y.sun> <20181031015417.GC15378@yi.y.sun> <20181031141030.GB13219@hirez.programming.kicks-ass.net> From: Waiman Long Organization: Red Hat Message-ID: Date: Wed, 31 Oct 2018 11:07:22 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20181031141030.GB13219@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 31 Oct 2018 15:07:24 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/31/2018 10:10 AM, Peter Zijlstra wrote: > On Wed, Oct 31, 2018 at 09:54:17AM +0800, Yi Sun wrote: >> On 18-10-23 17:33:28, Yi Sun wrote: >>> On 18-10-23 10:51:27, Peter Zijlstra wrote: >>>> Can you try and explain why vcpu_is_preempted() doesn't work for you? >>> I thought HvSpinWaitInfo is used to notify hypervisor the spin number >>> which is different with vcpu_is_preempted. So I did not consider >>> vcpu_is_preempted. >>> >>> But HvSpinWaitInfo is a quite simple function and could be combined >>> with vcpu_is_preempted together. So I think it is OK to use >>> vcpu_is_preempted to make codes clean. I will have a try. >> After checking codes, there is one issue to call vcpu_is_preempted. >> There are two spin loops in qspinlock_paravirt.h. One loop in >> 'pv_wait_node' calls vcpu_is_preempted. But another loop in >> 'pv_wait_head_or_lock' does not call vcpu_is_preempted. It also does >> not call any other ops of 'pv_lock_ops' in the loop. So I am afraid >> we have to add one more ops in 'pv_lock_ops' to do this. > Why? Would not something like the below cure that? Waiman, can you have > a look at this; I always forget how that paravirt crud works. There are two major reasons why the vcpu_is_preempt() test isn't done at pv_wait_head_or_lock(). First of all, we may not have a valid prev pointer after all if it is the first one to enter the queue while the lock is busy. Secondly, because of lock stealing, the cpu number pointed by a valid prev pointer may not be the actual cpu that is currently holding the lock. Another minor reason is that we want to minimize the lock transfer latency and so don't want to sleep too early while waiting at the queue head. Cheers, Longman