Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp4527996pxb; Sat, 12 Feb 2022 08:09:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQAZBVSH0TMJv+jm/hyFsaIhdIEGD3fatUKE2XSPYXn1S4FET4P/PlVpbsD0pYp+9ABApt X-Received: by 2002:a17:90b:2281:: with SMTP id kx1mr5871129pjb.37.1644682174627; Sat, 12 Feb 2022 08:09:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644682174; cv=none; d=google.com; s=arc-20160816; b=PHw/qXovLLumwIDH/ojcOFK7EphSYOwbNVHgAnXPUVgk0ywUUMZhanxZM/eCfOHcyz vD6++jT/bFr0kmAZA3J+xalYxB0kN/RFVJs1B4ANB9e7jPQwC9kr3AB52fbkqDTv7Okx r8jPF78zghX/DYhbc5/43fMf10WGxkM/ILgFZd87y/3BhZp2zhZnzhWSNjsnM+ARbSjy Tc+gHzIVIoB41qipwNKwPeNC2qgU4czc3+uD9FLwjsi0WVmAloPMgnlJCyliTHO/hsoJ LAzLMIXY9QOwg4fD+GAMA8vWZr9Ax0kuj3AbOoPybNYCe2+QLSHpPZbi1pUAuRvR8mfN EXBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=BHPbXDxWBtuDI9YYnGdugRaUKtQ7K4m6+zQLsPmD+c4=; b=yLsLOw1TV/xjY0FAsCBzIDeWv5EeZYYPHPHtQ8US15ItbZBfYWcrxoflO1Rggmpu7y 4StuyoZ7vZr1r/kJiJXp6g0vmbOKjFujD7Z4Fxq/8FsXpFE+wLjrCJzmH6c/gEmct00Y ZUbPMqSUCMLFRlEzfPwgMMZNc2MjcJU7eaBB+Kf3lrrNd7ZBYA/sdH9Ensk11JtUb+S+ TK1Tuq961L+vea95NgLuPKr2iUGVNhJPiQcKBfbjkp3E5ALHTMtotUaz7LQztBqosl5U r1Sjm4oJ3KNNmEeM94cGNTMeQGu2c8yfwgcE8CdUo7WEN2NonUljzPx5br6IKhhC36zW TMQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=dR8Q5ZU2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j15si6275122pjy.190.2022.02.12.08.09.21; Sat, 12 Feb 2022 08:09:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=dR8Q5ZU2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349621AbiBKLv1 (ORCPT + 93 others); Fri, 11 Feb 2022 06:51:27 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:41204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238409AbiBKLv0 (ORCPT ); Fri, 11 Feb 2022 06:51:26 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E68DFF4F; Fri, 11 Feb 2022 03:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=BHPbXDxWBtuDI9YYnGdugRaUKtQ7K4m6+zQLsPmD+c4=; b=dR8Q5ZU2i/N7HitiOzfANLpiaz 5qF/SGYCLXmE3e/dkF3v4vQlXl0pelPeb6ZkNEXzLADKV9kE23rp79jq4mfm03lr+heVNBw6SiiaY 6Z1pKGNxXXmfGBcyaBr6PSJcpbz8Sdshm9m2BBMjbHme/kSazx7WqGhKRwogi4Xwnv6NNTZsBkMSl FG16DeaXr1JW6GU+rgKjMw3/dKdJvXb6j/XE3kxeGiExzW4cOIhaKmi9tqzv+Uf1tvOu9gdhNB4qx +LB1CCgDn3ykbmNyqqv+jJyTAUNskEwK3OFdtohRrAqlCJ7QbjcAlAePlTps3tau2u4nzTWSfA3hd HZgeVPvg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1nIUSJ-00AN1Y-C0; Fri, 11 Feb 2022 11:51:15 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id 7C45D9853C7; Fri, 11 Feb 2022 12:51:14 +0100 (CET) Date: Fri, 11 Feb 2022 12:51:14 +0100 From: Peter Zijlstra To: Zhen Ni Cc: mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, mcgrof@kernel.org, keescook@chromium.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] sched: move rr_timeslice sysctls to rt.c Message-ID: <20220211115114.GU23216@worktop.programming.kicks-ass.net> References: <20220210060831.26689-1-nizhen@uniontech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220210060831.26689-1-nizhen@uniontech.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 10, 2022 at 02:08:31PM +0800, Zhen Ni wrote: > move rr_timeslice sysctls to rt.c and use the new > register_sysctl_init() to register the sysctl interface. > > Signed-off-by: Zhen Ni OK, I've had it with this nonsense. Can you *please* redo all of sched such that: - In the Subject:, the first letter after the subsystem prefix (sched:) is capitalized. - the lot actually applies to tip/sched/core (so far not a single one of these patches applied without needing -- mostly trivial -- fixups). - Do obvious cleanups.. see below. - Don't have more than a single *sysctl_init() per .c file. - It's a full series that does all instead of random little patches that conflict with one another when applied out of turn. > --- > include/linux/sched/sysctl.h | 3 --- > kernel/sched/rt.c | 28 ++++++++++++++++++++++++++-- > kernel/sysctl.c | 7 ------- > 3 files changed, 26 insertions(+), 12 deletions(-) > > diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h > index d416d8f45186..f6466040883c 100644 > --- a/include/linux/sched/sysctl.h > +++ b/include/linux/sched/sysctl.h > @@ -45,11 +45,8 @@ extern unsigned int sysctl_sched_uclamp_util_min_rt_default; > extern unsigned int sysctl_sched_autogroup_enabled; > #endif > > -extern int sysctl_sched_rr_timeslice; > extern int sched_rr_timeslice; Why leave sched_rr_timeslice here? It doesn't belong here. > +#ifdef CONFIG_SYSCTL > +static struct ctl_table sched_rr_sysctls[] = { > + { > + .procname = "sched_rr_timeslice_ms", > + .data = &sysctl_sched_rr_timeslice, > + .maxlen = sizeof(int), > + .mode = 0644, > + .proc_handler = sched_rr_handler, > + }, > + {} > +}; > + > +static void __init sched_rr_sysctl_init(void) > +{ > + register_sysctl_init("kernel", sched_rr_sysctls); > +} > +#else > +#define sched_rr_sysctl_init() do { } while (0) > +#endif > + > static int do_sched_rt_period_timer(struct rt_bandwidth *rt_b, int overrun); > > struct rt_bandwidth def_rt_bandwidth; > @@ -2471,6 +2494,7 @@ void __init init_sched_rt_class(void) > zalloc_cpumask_var_node(&per_cpu(local_cpu_mask, i), > GFP_KERNEL, cpu_to_node(i)); > } > + sched_rr_sysctl_init(); > } When I combine this with: patches/zhen_ni-sched-move_rt_period_runtime_sysctls_to_rt_c.patch That ends up as: @@ -2471,6 +2535,8 @@ void __init init_sched_rt_class(void) zalloc_cpumask_var_node(&per_cpu(local_cpu_mask, i), GFP_KERNEL, cpu_to_node(i)); } + sched_rt_sysctl_init(); + sched_rr_sysctl_init(); } #endif /* CONFIG_SMP */ Like srsly? So I've dropped the whole lot I had: patches/zhen_ni-sched-move_energy_aware_sysctls_to_topology_c.patch patches/zhen_ni-sched-move_cfs_bandwidth_slice_sysctls_to_fair_c.patch patches/zhen_ni-sched-move_uclamp_util_sysctls_to_core_c.patch patches/zhen_ni-sched-move_schedstats_sysctls_to_core_c.patch patches/zhen_ni-sched-move_deadline_period_sysctls_to_deadline_c.patch patches/zhen_ni-sched-move_rt_period_runtime_sysctls_to_rt_c.patch patches/zhen_ni-sched-move_rr_timeslice_sysctls_to_rt_c.patch And I expect a single coherent series or I'll forgo all this.