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: <20240806215535.GA36996@noisy.programming.kicks-ass.net>
Date: Tue, 6 Aug 2024 23:55:35 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Tejun Heo <tj@...nel.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

On Tue, Aug 06, 2024 at 11:34:19AM -1000, Tejun Heo wrote:

> > > +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?

There currently is not -- but if you need that, we can definitely add a
boolean argument or something. But I think it would be good if a policy
can inherently know if curr is the better pick.

ISTR you having two queue types, one FIFO and one vtime ordered, for
both I think it should be possible to determine order, right?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ