Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2866512pxb; Tue, 13 Apr 2021 12:08:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzUztrMriBsZd1mn6atNnkjbB65hPqWXw+Xp49Oc+IvCGB+mPvDGuDRPWQmq07o3xO+IjYD X-Received: by 2002:a05:6402:30ae:: with SMTP id df14mr36111255edb.97.1618340929232; Tue, 13 Apr 2021 12:08:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618340929; cv=none; d=google.com; s=arc-20160816; b=zyABkPjELg5u1AbbbdgrIOeCpraOhf7GNUSNe3DMKlExGAbbW0UZAsLKpmSTxkA7S5 0iuGqxOuLeAuL6ML7j6OuWz3fnOMVwDtwqt/uVt4uW3AaCWkEmpxuc3y4DZ9IIMlN5XY cofcrGVe6TllWb94PgTUOpZegxt2Y4siP2KxJrBS8zd9R1+8udKTOmkhn1lY45dckBpm tGYTzojblz33cAbWcBH0rhABPu9ZUYMIbFpZy6Z1xkhEC80hF5tDEmwAIY+gx2zyNL3J Dr4EqyuG9MhpoyN9XcaYht6PT4odHKDv5Tn/IeULVtpkUVXC8Dz8V3j3FplBjITG//e0 bCrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=BV+Y0yv4ts4LwmrIfhpI0d6yT3fk5Odfgha/1h9+/24=; b=ecx4w3tEg68oM/M8nLgAmSl/1IN8IrPL+xsR/KhDj/X2OteFF9683R1nFHOyP6lpTP 0KBI8zgP/UyetEflyDbjbnLrmwLJGnOsDXGJH8mYVjJbST26HOSEvHuUX8UxLELpyysW ishW1FaebHbMkHBIvq62ILXvzzhFLQjiTAGcES7Vff5OLSrhHrX8GxU3jFyEbRbLyygh OORArtOPqF0CeIaHXsfm13KuJGbeERxIF1FUg6uc0X/eKTVEjN0MDmbxI+DUb1W6U1In wbora3BSGBn/2VFSGMwaXP9D16jtm8GDzIo3lvPsZdxa7PEuTS9Xc5cAgbPEMT5zPd5q a97w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g10si12464edr.601.2021.04.13.12.08.26; Tue, 13 Apr 2021 12:08:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231721AbhDMOzm (ORCPT + 99 others); Tue, 13 Apr 2021 10:55:42 -0400 Received: from foss.arm.com ([217.140.110.172]:43588 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231378AbhDMOzl (ORCPT ); Tue, 13 Apr 2021 10:55:41 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6360D106F; Tue, 13 Apr 2021 07:55:21 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 99ACC3F694; Tue, 13 Apr 2021 07:55:19 -0700 (PDT) From: Valentin Schneider To: Peter Zijlstra , mingo@kernel.org, mgorman@suse.de, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, joshdon@google.com Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, greg@kroah.com, linux@rasmusvillemoes.dk Subject: Re: [PATCH v2 7/9] sched,debug: Convert sysctl sched_domains to debugfs In-Reply-To: <20210412102001.485107586@infradead.org> References: <20210412101421.609526370@infradead.org> <20210412102001.485107586@infradead.org> Date: Tue, 13 Apr 2021 15:55:15 +0100 Message-ID: <87lf9mmdyk.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/04/21 12:14, Peter Zijlstra wrote: > Stop polluting sysctl, move to debugfs for SCHED_DEBUG stuff. > > Signed-off-by: Peter Zijlstra (Intel) > Reviewed-by: Dietmar Eggemann On my Juno (2+4 big.LITTLE), sys/kernel/debug/sched/domains/ is now empty. I think that's because of unregister_sched_domain_sysctl() - debugfs_remove() is recursive, and I do get a case where we rebuild the domains but no CPU has been added or removed (we rebuild the domains when cpufreq kicks in, it's part of the big.LITTLE ponies). Do we actually still need that unregister? From a brief glance it looks like we could throw it out.