linux-kernel - Re: [GIT PULL] sched_ext: Initial pull request for v6.11

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: <ZrKW2wZTT3myBI0d@slm.duckdns.org>
Date: Tue, 6 Aug 2024 11:34:19 -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 Tue, Aug 06, 2024 at 11:10:02PM +0200, Peter Zijlstra wrote:
...
> > Right, I don't think it affects SCX in any significant way. Either way
> > should be fine.
> 
> So I just looked at things. And considering we currently want to have:
> 
>   pick_next_task := pick_task() + set_next_task(.first = true)
> 
> and want to, with those other patches moving put_prev_task() around, get
> to fully making pick_next_task() optional, it looks to me you're not
> quite there yet. Notably:

Oh yes, the code definitely needs updating. I just meant that the needed
changes are unlikely to be invasive.

...
> > +	p = first_local_task(rq);
> > +	if (!p)
> > +		return NULL;
> > +
> > +	set_next_task_scx(rq, p, true);
> > +
> > +	if (unlikely(!p->scx.slice)) {
> > +		if (!scx_ops_bypassing() && !scx_warned_zero_slice) {
> > +			printk_deferred(KERN_WARNING "sched_ext: %s[%d] has zero slice in pick_next_task_scx()\n",
> > +					p->comm, p->pid);
> > +			scx_warned_zero_slice = true;
> > +		}
> > +		p->scx.slice = SCX_SLICE_DFL;
> > +	}
> 
> This condition should probably move to set_next_task_scx(.first = true).

Sure.

...
> > +static struct task_struct *pick_task_scx(struct rq *rq)
> > +{
> > +	struct task_struct *curr = rq->curr;
> > +	struct task_struct *first = first_local_task(rq);
> > +
> > +	if (curr->scx.flags & SCX_TASK_QUEUED) {
> > +		/* is curr the only runnable task? */
> > +		if (!first)
> > +			return curr;
> > +
> > +		/*
> > +		 * Does curr trump first? We can always go by core_sched_at for
> > +		 * this comparison as it represents global FIFO ordering when
> > +		 * the default core-sched ordering is used and local-DSQ FIFO
> > +		 * ordering otherwise.
> > +		 *
> > +		 * We can have a task with an earlier timestamp on the DSQ. For
> > +		 * example, when a current task is preempted by a sibling
> > +		 * picking a different cookie, the task would be requeued at the
> > +		 * head of the local DSQ with an earlier timestamp than the
> > +		 * core-sched picked next task. Besides, the BPF scheduler may
> > +		 * dispatch any tasks to the local DSQ anytime.
> > +		 */
> > +		if (curr->scx.slice && time_before64(curr->scx.core_sched_at,
> > +						     first->scx.core_sched_at))
> > +			return curr;
> > +	}
> 
> And the above condition seems a little core_sched specific. Is that
> suitable for the primary pick function?

Would there be any distinction between pick_task() being called for regular
and core sched paths?

Thanks.

-- 
tejun