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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 64799C43381 for ; Sat, 2 Mar 2019 13:31:00 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2085E20857 for ; Sat, 2 Mar 2019 13:31:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ltHcxmrd"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="LCVp6w0A"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="K72nqP/k" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2085E20857 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1rkL5hEDvLNya0LTzltFKxcFPXNTMZsrdsIYUgBn5aw=; b=ltHcxmrdy6jYzw mXMQtnZF+a0HNeBtyMfxyF43WYyj8jxewT8EndBaSs2mZfDBlFMwfwZAVkeuZq8thfiNxIQUuewW/ yZD3BJe8M8aQ5nqJMgpbfBnWDqk5swX3n+KN6OT/61spy+5SOyNozsBAVdF7g/W0EHmHHikWcjk4x 19x6o4Mbe407ODIhJ9c+K5mg2pCY550mmdInEOVUpvRu6+i3+SYXrVRvDnuDmfOzW9x3FOUTOULHM jQMQAeMB4Fn0eYCZeXJzDW3QOdmbZsfkf+tmu+AViYeGVW1fp1hRI/Zqfs1Q8wo1cuklDUwsRlJv2 n9aMULDVyafPvfIgY5mA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h04j8-0003ja-Jv; Sat, 02 Mar 2019 13:30:54 +0000 Received: from smtp.codeaurora.org ([198.145.29.96]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h04j4-0003j1-Hd for linux-arm-kernel@lists.infradead.org; Sat, 02 Mar 2019 13:30:52 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 0340060CF0; Sat, 2 Mar 2019 13:30:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1551533448; bh=btk3Yo4vRkn5TsaEYec+sCMeCT9iGiqmpAs8yzufPPM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LCVp6w0AiF9MJCzw+8J4fEWsb2eRvs5UALp9BV7h/puP2IGpvX8TOVXfboeRe457B hhe8tq5an5gNNtXhrrMQiGYHnfw2a8mZeass2K/op4fsFJOD1Kg6gIqUOR5sSAe2H1 y9kXkmWb0rJ31XgFzq6hsrFcru1vvgb+lq0YdryU= Received: from [192.168.1.101] (unknown [183.83.69.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: clingutla@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id CDB5560A42; Sat, 2 Mar 2019 13:30:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1551533447; bh=btk3Yo4vRkn5TsaEYec+sCMeCT9iGiqmpAs8yzufPPM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=K72nqP/kmK8csKWgEHGe/7x4Y4UzqaatmK0ZPLKR4oQab1nXS9xcNq+YsE1lSZPtk W4u0lDsP4DPwGmRnQG79a3BIedzG89W93yXTlkZdRFbtk2VCsWPV2g5Ta63xQVr+yT DXm1PDwSWwt/V8WA7fzM4bxoJ5b8gY74xcKnImOI= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org CDB5560A42 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=clingutla@codeaurora.org Subject: Re: [PATCH] arch_topology: Update user supplied capacity to possible cpus in cluster To: Sudeep Holla References: <1551354838-29902-1-git-send-email-clingutla@codeaurora.org> <20190228121901.GA26207@e107155-lin> <6d7eb7cc-2453-3a7b-9163-ef9a5389220f@codeaurora.org> <20190228152555.GA13165@e107155-lin> From: Chandra Sekhar Lingutla Message-ID: <5785fd91-3d76-78e6-f4c5-7ed07be1a14d@codeaurora.org> Date: Sat, 2 Mar 2019 19:00:43 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <20190228152555.GA13165@e107155-lin> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190302_053050_631153_5A6578F7 X-CRM114-Status: GOOD ( 20.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: catalin.marinas@arm.com, will.deacon@arm.com, dietmar.eggemann@arm.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/28/2019 8:55 PM, Sudeep Holla wrote: > On Thu, Feb 28, 2019 at 08:08:13PM +0530, Chandra Sekhar Lingutla wrote: >> Hi Sudeep, >> >> On 2/28/2019 5:49 PM, Sudeep Holla wrote: >>> On Thu, Feb 28, 2019 at 05:23:58PM +0530, Lingutla Chandrasekhar wrote: >>>> With commit '5bdd2b3f0f8 ("arm64: topology: add support to remove cpu >>>> topology sibling masks")', when cpu hotplugged out, it resets the cpu >>>> information in its sibling CPUs. If user changes capacity of any cpu, >>>> then the new capacity applied to all online cpus in the cluster. >>>> >>> Correct but you are now changing to apply the same to all the CPUs >>> in the package which is wrong. >>> >>>> If any hot plugged out cpu in the same cluster comes back to online, >>>> then that would have different/stale capacity value. >>>> >>> Why not save the value ? >> Sorry, didn't get you, you mean save user supplied value ? > I meant save the last user set value and reset when CPU comes online. But 'cpu_capacity' for hot plugging cpu is not touched, so it would retain same value. The actual problem is, cpu_capacity_store() tries to change the capacity for all its 'sibling cpus'. Now the commit '5bdd2b3f0f8' keeps only online cpus in the sibling mask, so user supplied cpu_capacity would be applied only online sibling cpus at the time. After that, if any cpu hot plugged in, it would have different cpu_capacity than its siblings. >>>> Fix it by applying user supplied capacity to all possible cpus in the >>>> cluster. >>>> >>> NACK for the change. It changes for all the CPUs in the package/socket. >>> Though DT platforms have cluster ids as package ids, that's wrong and >>> must be fixed. So you need to fix this issuw without depending on the >>> package id. I have removed all the wrong users of the same and this is >>> also a wrong usage. >> I presumed all cores with same package-id have same cpu capacity, so >> depended on it. > No, > 1. Package is not cluster, it's the physical socket which on typical > mobile systems will be the whole SoC. So it includes all the CPUs > in the system. > > 2. How about DSU systems where CPUs can have different capacity within > cluster ? So cpus in cpu_topology->core_sibling mask would not need to have same capacity_cpu? Then i think, we should update the cpu_capacity for only requested cpu right? ex: 'echo 910 > sys/devices/system/cpu/cpu5/cpu_capacity' should be applied only to cpu5. >> I think, we can update the capacity of newly online cpu by reading its >> core_sibling cpu capacity. > Will that survive scenario where all the CPUs in the so-called cluster > is hot-plugged out and back in. > >> Let me know your opinion on this option ? >> > I see only solution is to save the value last set from the user somewhere > if not already done and restore the same. > > -- > Regards, > Sudeep -- Chandrasekhar L, -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel