[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y9hiifiFx4TeUdTo@slm.duckdns.org>
Date: Mon, 30 Jan 2023 14:36:25 -1000
From: Tejun Heo <tj@...nel.org>
To: Josh Don <joshdon@...gle.com>
Cc: torvalds@...ux-foundation.org, mingo@...hat.com,
peterz@...radead.org, 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,
brho@...gle.com, pjt@...gle.com, derkling@...gle.com,
haoluo@...gle.com, dvernet@...a.com, dschatzberg@...a.com,
dskarlat@...cmu.edu, riel@...riel.com,
linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
kernel-team@...a.com
Subject: Re: [PATCH 27/30] sched_ext: Implement core-sched support
On Mon, Jan 30, 2023 at 02:26:20PM -1000, Tejun Heo wrote:
> However, the BPF scheduler is free to dispatch whatever tasks anytime (e.g.
> scx_example_central), so it's possible that a task with an earlier timestamp
> has been dispatched to the local DSQ since curr started executing, in which
> case we likely want to return the first on DSQ as the CPU's candidate.
Okay, a more common case would be when a CPU is forced to run a task which
isn't current by its sibling winning a different cookie and then the BPF
scheduler putting that task right back on the local DSQ. For the CPU then,
the right candidate would be the first task on DSQ not the current running
one which is dragged forward because the sibling trumping us.
Thanks.
--
tejun
Powered by blists - more mailing lists