[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ddfca6ac-f7a6-4b51-80e8-2e422de7d597@linux.alibaba.com>
Date: Tue, 29 Oct 2024 10:07:36 +0800
From: Tianchen Ding <dtcccc@...ux.alibaba.com>
To: Tejun Heo <tj@...nel.org>
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
On 2024/10/29 01:37, Tejun Heo wrote:
> Hello,
>
> On Mon, Oct 28, 2024 at 02:33:13PM +0800, Tianchen Ding wrote:
>> Introduce "cpu.fair_slice" for cgroup v2 and "cpu.fair_slice_us" for v1
>> according to their name styles. The unit is always microseconds.
>>
>> A cgroup with shorter slice can preempt others more easily. This could be
>> useful in container scenarios.
>>
>> By default, cpu.fair_slice is 0, which means the slice of se is
>> calculated by min_slice from its cfs_rq. If cpu.fair_slice is set, it
>> will overwrite se->slice with the customized value.
>
> Provided that this tunable is necessary, wouldn't it be more useful to
> figure out what per-task interface would look like first? Maybe there are
> cases where per-cgroup slice config makes sense but that sounds
> significantly less useful than being able to configure it per-task.
>
> Thanks.
>
For eevdf, per-task interface has been introduced in commit 857b158dc5e8
("sched/eevdf: Use sched_attr::sched_runtime to set request/slice suggestion")
So This patch is trying to introduce a cgroup level interface.
Thanks.
Powered by blists - more mailing lists