[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zruwioj86jQz8Oq6@slm.duckdns.org>
Date: Tue, 13 Aug 2024 09:14:18 -1000
From: Tejun Heo <tj@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, David Vernet <void@...ifault.com>,
Ingo Molnar <mingo@...hat.com>, Alexei Starovoitov <ast@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] sched_ext: Initial pull request for v6.11
Hello, Peter.
On Sat, Aug 10, 2024 at 10:45:42PM +0200, Peter Zijlstra wrote:
...
> > It is tricky because the kernel part can't make assumptions about whether
> > two tasks are even on the same timeline. In the usual scheduling path, this
> > isn't a problem as the decision is made by the BPF scheduler from balance()
> > - if it wants to keep running the current task, it doesn't dispatch a new
> > one. Otherwise, it dispatches the next task.
>
> But I have a question.. don't you clear scx.slice when a task needs to
> be preempted? That is, why isn't that condition sufficient to determine
> if curr has precedence over the first queued? If curr and it is still
> queued and its slice is non-zero, take curr.
scx.slice is used a bit different from other sched classes mostly because
there are two layers - the SCX core and the BPF scheduler itself. The BPF
scheduler uses scx.slice to tell the SCX core to "don't bother asking about
it until the current slice has been exhausted" - ie. it's a way to offload
things like tick handling and preemption by higher priority sched classes to
SCX core. When scx.slice expires, the BPF scheduler's dispatch() is called
which can then decide whether to replenish the slice of the current task or
something else should run and so on.
Thanks.
--
tejun
Powered by blists - more mailing lists