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=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,USER_AGENT_MUTT 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 1558FC43381 for ; Thu, 7 Mar 2019 07:29:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CCF6D20675 for ; Thu, 7 Mar 2019 07:29:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XGBL6qPT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726140AbfCGH3C (ORCPT ); Thu, 7 Mar 2019 02:29:02 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:32817 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725747AbfCGH3B (ORCPT ); Thu, 7 Mar 2019 02:29:01 -0500 Received: by mail-wr1-f65.google.com with SMTP id i12so16140715wrw.0 for ; Wed, 06 Mar 2019 23:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/0q1d1YjlgG6B/Hi2ywJV0dia9haEF2gLs3zPkjPLog=; b=XGBL6qPTz5AEPC/X882TszeiostpZBjaKd1waEJuAJQUk53YBT3mp7tE7o0buVXaIS gzmJ1BARp7YUVFtjGh32BV+u3x90jYYuWRQtjhfSpVHbm5b4LpFV/tSoh3B123JwlsYW 4wxQ1aLPny0iUoNOW7ifrzWpTKL1aCqjysmnyrYXtcJhrM3c7Xym9PMPQUOPh0lkZiA5 vP+LK/sSwTqpXq8HM74ZIDM/tcGiXNkYk0wmlRmBgE+fue1VRG2QNi+Z1cerrEiUcRdq PljD8RDaxEqpiAm8ICEffKoQzEO1/tvE6uCu+Mpun++wWUtdL3RdAnUlqwaZnEIKn9ut qdCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/0q1d1YjlgG6B/Hi2ywJV0dia9haEF2gLs3zPkjPLog=; b=fQJQjuPEQWg7T9TZkm7E3ZiHc97Ck/nMINvk2sQFddEo6f+E1W6Z1gZmeOH+HnY1Gl VCWNULVBuMbDfkfve6BUXSJLMT7EXlDcXeDGDJYeq4DE7y5B+pcaOtPgWwVtQRm/of62 tHDc4KW9Avo7qyh/yPMs0LWohwFSvDdWPRzB+OxWLhbaT2jRe56Pfg1yZ5Iw+EC5R22e E6/IM+W8FPqP3XT5AbQP+G/qQc0DfQWG0J1g9Dw3+ylWOUirroPnjjNkZaTXeiFrAzF6 ndczNp8W2+Fx8jphnn36rmHeXq6dIe+30dGOqZ43Fin6VoXFCw0scArcpHQXGusYLb1D JWdQ== X-Gm-Message-State: APjAAAWzuoPZiy+QYL0zi1OYCErQHcSIDKwpPpowedkBSQ6aZYr0Avl6 23DxyFFZn503rPx1UBVExGuesBcf X-Google-Smtp-Source: APXvYqzW8hDPoNb8ghbVx5FHbfsHtK8WqSx0jK9HAZuqk7FaYuHyqRFIedt4w7Y+DcYjlzfNSgkVGA== X-Received: by 2002:adf:9167:: with SMTP id j94mr6048871wrj.106.1551943739540; Wed, 06 Mar 2019 23:28:59 -0800 (PST) Received: from localhost.localdomain ([151.15.252.68]) by smtp.gmail.com with ESMTPSA id u13sm9315252wmf.3.2019.03.06.23.28.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 06 Mar 2019 23:28:58 -0800 (PST) Date: Thu, 7 Mar 2019 08:28:56 +0100 From: Juri Lelli To: Lingutla Chandrasekhar Cc: quentin.perret@arm.com, sudeep.holla@arm.com, dietmar.eggemann@arm.com, gregkh@linuxfoundation.org, will.deacon@arm.com, catalin.marinas@arm.com, morten.rasmussen@arm.com, linux-arm-kernel@lists.infradead.org, jeremy.linton@arm.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] arch_topology: Make cpu_capacity sysfs node as ready-only Message-ID: <20190307072856.GC29753@localhost.localdomain> References: <20190306152254.GB19434@e105550-lin.cambridge.arm.com> <1551886073-16217-1-git-send-email-clingutla@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1551886073-16217-1-git-send-email-clingutla@codeaurora.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 06/03/19 20:57, Lingutla Chandrasekhar wrote: > If user updates any cpu's cpu_capacity, then the new value is going to > be applied to all its online sibling cpus. But this need not to be correct > always, as sibling cpus (in ARM, same micro architecture cpus) would have > different cpu_capacity with different performance characteristics. > So updating the user supplied cpu_capacity to all cpu siblings > is not correct. > > And another problem is, current code assumes that 'all cpus in a cluster > or with same package_id (core_siblings), would have same cpu_capacity'. > But with commit '5bdd2b3f0f8 ("arm64: topology: add support to remove > cpu topology sibling masks")', when a cpu hotplugged out, the cpu > information gets cleared in its sibling cpus. So user supplied > cpu_capacity would be applied to only online sibling cpus at the time. > After that, if any cpu hot plugged in, it would have different cpu_capacity > than its siblings, which breaks the above assumption. > > So instead of mucking around the core sibling mask for user supplied > value, use device-tree to set cpu capacity. And make the cpu_capacity > node as read-only to know the assymetry between cpus in the system. > > Signed-off-by: Lingutla Chandrasekhar > --- > drivers/base/arch_topology.c | 33 +-------------------------------- > 1 file changed, 1 insertion(+), 32 deletions(-) > > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index edfcf8d..d455897 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -7,7 +7,6 @@ > */ > > #include > -#include > #include > #include > #include > @@ -51,37 +50,7 @@ static ssize_t cpu_capacity_show(struct device *dev, > static void update_topology_flags_workfn(struct work_struct *work); > static DECLARE_WORK(update_topology_flags_work, update_topology_flags_workfn); > > -static ssize_t cpu_capacity_store(struct device *dev, > - struct device_attribute *attr, > - const char *buf, > - size_t count) > -{ > - struct cpu *cpu = container_of(dev, struct cpu, dev); > - int this_cpu = cpu->dev.id; > - int i; > - unsigned long new_capacity; > - ssize_t ret; > - > - if (!count) > - return 0; > - > - ret = kstrtoul(buf, 0, &new_capacity); > - if (ret) > - return ret; > - if (new_capacity > SCHED_CAPACITY_SCALE) > - return -EINVAL; > - > - mutex_lock(&cpu_scale_mutex); > - for_each_cpu(i, &cpu_topology[this_cpu].core_sibling) > - topology_set_cpu_scale(i, new_capacity); > - mutex_unlock(&cpu_scale_mutex); > - > - schedule_work(&update_topology_flags_work); > - > - return count; > -} > - > -static DEVICE_ATTR_RW(cpu_capacity); > +static DEVICE_ATTR_RO(cpu_capacity); There are cases in which this needs to be RW, as recently discussed https://lore.kernel.org/lkml/20181123135807.GA14964@e107155-lin/ IMHO, if the core_sibling assumption doesn't work in all cases, one should be looking into fixing it, rather than making this RO. Best, - Juri 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=-8.2 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 6A9E9C43381 for ; Thu, 7 Mar 2019 07:29:21 +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 3341B20675 for ; Thu, 7 Mar 2019 07:29:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TXfP9Rsb"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XGBL6qPT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3341B20675 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3/IsE8yjP4qWrFd6aJcg7BJKPnuN29N1qvZcznzh/Co=; b=TXfP9Rsbr200MK V0xS/Qm6d62vMPFGO17e+ddFXlRE6GN0h9TllGPQr1W+3i7llOU7bJJqFVrX0UPZL7Okpky24RDLt KDLNWqFGS17gplq/IeGDr3BZse6mGpgHaFLRu5meAtDep3EgADkujUFFkBRum52URJZta34JC/OzE kjaopMOJvONSE55IvsOUNcE5it39mgqeCK1Vx3xi29njBieA1AqY7Ios2sjolYYC0ip5HJFCSNOBR ejFVqe8V7uegUzNnY9yUYgIWMRuDkfSI+ELe5bTLG99Lxhs+S1AQr3tmSwh4PDMgPaCWLy9H9gquS XRCxyECPwcNzWFWMPVMw==; 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 1h1nSk-0005A6-0n; Thu, 07 Mar 2019 07:29:06 +0000 Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h1nSg-0004n9-5U for linux-arm-kernel@lists.infradead.org; Thu, 07 Mar 2019 07:29:03 +0000 Received: by mail-wr1-x442.google.com with SMTP id t18so16161188wrx.2 for ; Wed, 06 Mar 2019 23:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/0q1d1YjlgG6B/Hi2ywJV0dia9haEF2gLs3zPkjPLog=; b=XGBL6qPTz5AEPC/X882TszeiostpZBjaKd1waEJuAJQUk53YBT3mp7tE7o0buVXaIS gzmJ1BARp7YUVFtjGh32BV+u3x90jYYuWRQtjhfSpVHbm5b4LpFV/tSoh3B123JwlsYW 4wxQ1aLPny0iUoNOW7ifrzWpTKL1aCqjysmnyrYXtcJhrM3c7Xym9PMPQUOPh0lkZiA5 vP+LK/sSwTqpXq8HM74ZIDM/tcGiXNkYk0wmlRmBgE+fue1VRG2QNi+Z1cerrEiUcRdq PljD8RDaxEqpiAm8ICEffKoQzEO1/tvE6uCu+Mpun++wWUtdL3RdAnUlqwaZnEIKn9ut qdCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/0q1d1YjlgG6B/Hi2ywJV0dia9haEF2gLs3zPkjPLog=; b=kYmjnjNVDk5M964w/SA41iWTh14jnc8LqeomWx7Jn38BWB4Cd6g+gQqYyLB8twr0R4 XALEUu1U2vlELCzqgGRCKr47bOMU+0T4jm0CABm3QC/WruyIHUnqFIc8ZbVqGFa7l7DA JoKS30r37jScpj5b4rJFipNx1ZXOaOgyejkAn9urgoGkg6ebrnV123Xsq/hGFFd59Eri +ZY/2T0QKhm8A25LVito2QiOMSAclcsN7XZscsGPqiZmteXAvN1rcG459mJQnjKaSi7I d8pQVx//r1YRjPr+c+/EfVUH+hLCEo9OqBV4+dDHNKz2DIzTcgNI4TFqUc9QbX3ox+Tc qvSg== X-Gm-Message-State: APjAAAWiy6XaTmTK7+Yo0fiA7dyhcajTzjveSlxI6L8z2J2tQ0xIKbN+ 75hMkIIRwcIqZY4EntaePZg= X-Google-Smtp-Source: APXvYqzW8hDPoNb8ghbVx5FHbfsHtK8WqSx0jK9HAZuqk7FaYuHyqRFIedt4w7Y+DcYjlzfNSgkVGA== X-Received: by 2002:adf:9167:: with SMTP id j94mr6048871wrj.106.1551943739540; Wed, 06 Mar 2019 23:28:59 -0800 (PST) Received: from localhost.localdomain ([151.15.252.68]) by smtp.gmail.com with ESMTPSA id u13sm9315252wmf.3.2019.03.06.23.28.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 06 Mar 2019 23:28:58 -0800 (PST) Date: Thu, 7 Mar 2019 08:28:56 +0100 From: Juri Lelli To: Lingutla Chandrasekhar Subject: Re: [PATCH v1] arch_topology: Make cpu_capacity sysfs node as ready-only Message-ID: <20190307072856.GC29753@localhost.localdomain> References: <20190306152254.GB19434@e105550-lin.cambridge.arm.com> <1551886073-16217-1-git-send-email-clingutla@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1551886073-16217-1-git-send-email-clingutla@codeaurora.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190306_232902_237042_9FFB6C11 X-CRM114-Status: GOOD ( 21.89 ) 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, sudeep.holla@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, jeremy.linton@arm.com, morten.rasmussen@arm.com, quentin.perret@arm.com, gregkh@linuxfoundation.org, 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 Hi, On 06/03/19 20:57, Lingutla Chandrasekhar wrote: > If user updates any cpu's cpu_capacity, then the new value is going to > be applied to all its online sibling cpus. But this need not to be correct > always, as sibling cpus (in ARM, same micro architecture cpus) would have > different cpu_capacity with different performance characteristics. > So updating the user supplied cpu_capacity to all cpu siblings > is not correct. > > And another problem is, current code assumes that 'all cpus in a cluster > or with same package_id (core_siblings), would have same cpu_capacity'. > But with commit '5bdd2b3f0f8 ("arm64: topology: add support to remove > cpu topology sibling masks")', when a cpu hotplugged out, the cpu > information gets cleared in its sibling cpus. So user supplied > cpu_capacity would be applied to only online sibling cpus at the time. > After that, if any cpu hot plugged in, it would have different cpu_capacity > than its siblings, which breaks the above assumption. > > So instead of mucking around the core sibling mask for user supplied > value, use device-tree to set cpu capacity. And make the cpu_capacity > node as read-only to know the assymetry between cpus in the system. > > Signed-off-by: Lingutla Chandrasekhar > --- > drivers/base/arch_topology.c | 33 +-------------------------------- > 1 file changed, 1 insertion(+), 32 deletions(-) > > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index edfcf8d..d455897 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -7,7 +7,6 @@ > */ > > #include > -#include > #include > #include > #include > @@ -51,37 +50,7 @@ static ssize_t cpu_capacity_show(struct device *dev, > static void update_topology_flags_workfn(struct work_struct *work); > static DECLARE_WORK(update_topology_flags_work, update_topology_flags_workfn); > > -static ssize_t cpu_capacity_store(struct device *dev, > - struct device_attribute *attr, > - const char *buf, > - size_t count) > -{ > - struct cpu *cpu = container_of(dev, struct cpu, dev); > - int this_cpu = cpu->dev.id; > - int i; > - unsigned long new_capacity; > - ssize_t ret; > - > - if (!count) > - return 0; > - > - ret = kstrtoul(buf, 0, &new_capacity); > - if (ret) > - return ret; > - if (new_capacity > SCHED_CAPACITY_SCALE) > - return -EINVAL; > - > - mutex_lock(&cpu_scale_mutex); > - for_each_cpu(i, &cpu_topology[this_cpu].core_sibling) > - topology_set_cpu_scale(i, new_capacity); > - mutex_unlock(&cpu_scale_mutex); > - > - schedule_work(&update_topology_flags_work); > - > - return count; > -} > - > -static DEVICE_ATTR_RW(cpu_capacity); > +static DEVICE_ATTR_RO(cpu_capacity); There are cases in which this needs to be RW, as recently discussed https://lore.kernel.org/lkml/20181123135807.GA14964@e107155-lin/ IMHO, if the core_sibling assumption doesn't work in all cases, one should be looking into fixing it, rather than making this RO. Best, - Juri _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel