Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp906462ybg; Fri, 18 Oct 2019 09:06:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqyTAn/iZkoYEVgQaht/Wn5rXR11Je3quH+Ip0UtNvzBLBeJurDyHwDFj8w6hXiEDz26unQ0 X-Received: by 2002:a50:eb95:: with SMTP id y21mr10533472edr.155.1571414760793; Fri, 18 Oct 2019 09:06:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571414760; cv=none; d=google.com; s=arc-20160816; b=PtkS/20dz5lb6FXUeVGfxyn8t8+FFBe4HCMLTYmsGa8fcj9f6ze4G6kEVajzYeWA9b zXbu58eDUV9m6S3IeomRr52RIOwsyq3Ry2M6HPA0+Em9Ic/zdpCiUCluXYHgsTpBP47v KBFhK0CJBy8j3T5QahYlkn6gG3aEjGjIxOqzEx7ualdY/yUvFHVKnbJK3QAXYIFIVf3n uhLQYFijZonQZ/eSzgcoQOl5W89ga/QFVXnvGP7N4wob36/ORPdMyZoFWHJspxdXK04Z cNLgC8D7+6PLTgASjI7J2L94pu5C2x/4BF2rr7+gaVnKN6zmPyvMHDYla4wJx+CfSeSs Dmfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=otn2YfGCJXXkyWoRW0WySWuulygDmLmpxSrhdfkGkUc=; b=F1rxTFRzJphRedp7xrQABgrLCjacIXiXj49v76HoiYNyQTbGseijiuC/tDEhxPwrlA gNGmNZaIaeFE2ewhvFPSTtUj3so9ie0014iy8RtjiKkq9u9NQjyNL7qcPB4l0ubESW7/ II1ZRJAQvvsRjTkPQP4TEXBG15TFmkHOpvQAVBwautkqtKlwthPoh76HHbRyPlC/p774 gNFLMHYuJ/m/oglMy4Lq1OfTbcdYYLqDZCAkqLdbQxc8TETe4ciTGstWOIQw5Ax/sn0F 5hLrOMUzzGlm8EAbqEyC6dj95ceObtoUX7BunIb3/SFRdQAIAs8A0R/JIdpZEAaekvWc ZC8A== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r19si3904180edy.409.2019.10.18.09.05.37; Fri, 18 Oct 2019 09:06:00 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394544AbfJQN0b (ORCPT + 99 others); Thu, 17 Oct 2019 09:26:31 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:35704 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726686AbfJQN0b (ORCPT ); Thu, 17 Oct 2019 09:26:31 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 2A379D7E05CBE2145065; Thu, 17 Oct 2019 21:26:29 +0800 (CST) Received: from [127.0.0.1] (10.177.251.225) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.439.0; Thu, 17 Oct 2019 21:26:19 +0800 Subject: Re: [PATCH V2] arm64: psci: Reduce waiting time of cpu_psci_cpu_kill() To: Sudeep Holla CC: David Laight , "catalin.marinas@arm.com" , "will@kernel.org" , "kstewart@linuxfoundation.org" , "gregkh@linuxfoundation.org" , "ard.biesheuvel@linaro.org" , "tglx@linutronix.de" , "wuyun.wu@huawei.com" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , , References: <18068756-0f39-6388-3290-cf03746e767d@huawei.com> <9df267db-e647-a81d-16bb-b8bfb06c2624@huawei.com> <20191016153221.GA8978@bogus> From: Yunfeng Ye Message-ID: <0f550044-9ed2-5f72-1335-73417678ba45@huawei.com> Date: Thu, 17 Oct 2019 21:26:15 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20191016153221.GA8978@bogus> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.251.225] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/10/16 23:32, Sudeep Holla wrote: > On Wed, Oct 09, 2019 at 12:45:16PM +0800, Yunfeng Ye wrote: >> If psci_ops.affinity_info() fails, it will sleep 10ms, which will not >> take so long in the right case. Use usleep_range() instead of msleep(), >> reduce the waiting time, and give a chance to busy wait before sleep. >> >> Signed-off-by: Yunfeng Ye >> --- >> V1->V2: >> - use usleep_range() instead of udelay() after waiting for a while >> >> arch/arm64/kernel/psci.c | 17 +++++++++++++---- >> 1 file changed, 13 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c >> index c9f72b2..99b3122 100644 >> --- a/arch/arm64/kernel/psci.c >> +++ b/arch/arm64/kernel/psci.c >> @@ -82,6 +82,7 @@ static void cpu_psci_cpu_die(unsigned int cpu) >> static int cpu_psci_cpu_kill(unsigned int cpu) >> { >> int err, i; >> + unsigned long timeout; >> >> if (!psci_ops.affinity_info) >> return 0; >> @@ -91,16 +92,24 @@ static int cpu_psci_cpu_kill(unsigned int cpu) >> * while it is dying. So, try again a few times. >> */ >> >> - for (i = 0; i < 10; i++) { >> + i = 0; >> + timeout = jiffies + msecs_to_jiffies(100); >> + do { >> err = psci_ops.affinity_info(cpu_logical_map(cpu), 0); >> if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) { >> pr_info("CPU%d killed.\n", cpu); >> return 0; >> } >> >> - msleep(10); >> - pr_info("Retrying again to check for CPU kill\n"); > > You dropped this message, any particular reason ? > When reduce the time interval to 1ms, the print message maybe increase 10 times. on the other hand, cpu_psci_cpu_kill() will print message on success or failure, which this retry log is not very necessary. of cource, I think use pr_info_once() instead of pr_info() is better. thanks. >> - } >> + /* busy-wait max 1ms */ >> + if (i++ < 100) { >> + cond_resched(); >> + udelay(10); >> + continue; > > Why can't it be simple like loop of 100 * msleep(1) instead of loop of > 10 * msleep(10). The above initial busy wait for 1 ms looks too much > optimised for your setup where it takes 50-500us, what if it take just > over 1 ms ? > msleep() is implemented by jiffies. when HZ=100 or HZ=250, msleep(1) is not accurate. so I think usleep_range() is better. 1 ms looks simple and good, but how about 100us is better? I refer a function sunxi_mc_smp_cpu_kill(), it use usleep_range(50, 100). thanks. > We need more generic solution. > > -- > Regards, > Sudeep > > . >