[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZyB-QdXryezwSswB@slm.duckdns.org>
Date: Mon, 28 Oct 2024 20:18:41 -1000
From: Tejun Heo <tj@...nel.org>
To: Tianchen Ding <dtcccc@...ux.alibaba.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Valentin Schneider <vschneid@...hat.com>
Subject: Re: [RFC PATCH 2/2] sched/eevdf: Introduce a cgroup interface for
slice
Hello,
On Tue, Oct 29, 2024 at 10:07:36AM +0800, Tianchen Ding wrote:
....
> For eevdf, per-task interface has been introduced in commit 857b158dc5e8
> ("sched/eevdf: Use sched_attr::sched_runtime to set request/slice
> suggestion")
I see.
> So This patch is trying to introduce a cgroup level interface.
If I'm reading the code correctly, the property can be set per task and is
inherited when forking unless RESET_ON_FORK is set. I'm not sure the cgroup
interface adds all that much:
- There's no inherent hierarchical or grouping behavior. I don't think it
makes sense for cgroup config to override per-thread configs.
- For cgroup-wide config, setting it in the seed process of the cgroup would
suffice in most cases. Changing it afterwards is more awkward but not
hugely so. If racing against forks is a concern, you can either use the
freezer or iterate until no new tasks are seen.
Thanks.
--
tejun
Powered by blists - more mailing lists