linux-kernel - Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d650aad701652ba1e4ca2052a8880e51904b8d17.camel@surriel.com>
Date: Tue, 07 May 2024 15:47:05 -0400
From: Rik van Riel <riel@...riel.com>
To: Tejun Heo <tj@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, torvalds@...ux-foundation.org, 
 mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org, 
 dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
 mgorman@...e.de,  bristot@...hat.com, vschneid@...hat.com, ast@...nel.org,
 daniel@...earbox.net,  andrii@...nel.org, martin.lau@...nel.org,
 joshdon@...gle.com, brho@...gle.com,  pjt@...gle.com, derkling@...gle.com,
 haoluo@...gle.com, dvernet@...a.com,  dschatzberg@...a.com,
 dskarlat@...cmu.edu, changwoo@...lia.com, himadrics@...ia.fr, 
 memxor@...il.com, andrea.righi@...onical.com, joel@...lfernandes.org, 
 linux-kernel@...r.kernel.org, bpf@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class

On Tue, 2024-05-07 at 09:33 -1000, Tejun Heo wrote:
> On Mon, May 06, 2024 at 02:47:47PM -0400, Rik van Riel wrote:
> 
> 
> >    I believe this can be solved with the same idea I had for
> >    reimplementing CONFIG_CFS_BANDWIDTH. Specifically, the code that
> >    determines the time slice length for a task already has a way to
> >    determine whether a CPU is "overloaded", and time slices need to
> > be
> >    shortened. Once we reach that situation, we can place woken up
> > tasks on
> >    a secondary heap of per-cgroup runqueues, from which we do not
> > directly
> >    run tasks, but pick the lowest vruntime task from the lowest
> > vruntime
> >    cgroup and put that on the main runqueue, if the previously
> > running
> 
> When overloaded, are the cgroups being put on a single rbtree? If so,
> they'd
> be using flattened shares, right? I wonder what you're suggesting for
> the
> overloaded case is pretty simliar to what flatcg is doing plus
> avoiding one
> level of indirection while not overloaded.

It does indeed sound like flatcg is doing almost the same thing.

I'm not entirely sure what to make of the fact that we both
came up with the same solution to the problem. I suppose it's
a nice improvement over a fully hierarchical solution, especially
when it comes to overhead, but there is still a fair amount of
complexity left.

I don't know if there is a simpler solution to this problem.

There might not be.

-- 
All Rights Reversed.