linux-kernel - Re: [PATCH 04/14] sched: SCHED_DEADLINE SMP-related data structures & logic.

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: <20131121094150.26318fe9@gandalf.local.home>
Date:	Thu, 21 Nov 2013 09:41:50 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Juri Lelli <juri.lelli@...il.com>
Cc:	peterz@...radead.org, tglx@...utronix.de, mingo@...hat.com,
	oleg@...hat.com, fweisbec@...il.com, darren@...art.com,
	johan.eker@...csson.com, p.faure@...tech.ch,
	linux-kernel@...r.kernel.org, claudio@...dence.eu.com,
	michael@...rulasolutions.com, fchecconi@...il.com,
	tommaso.cucinotta@...up.it, nicola.manica@...i.unitn.it,
	luca.abeni@...tn.it, dhaval.giani@...il.com, hgu1972@...il.com,
	paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
	insop.song@...il.com, liming.wang@...driver.com, jkacur@...hat.com,
	harald.gustafsson@...csson.com, vincent.guittot@...aro.org,
	bruce.ashfield@...driver.com
Subject: Re: [PATCH 04/14] sched: SCHED_DEADLINE SMP-related data structures
 & logic.

On Thu, 21 Nov 2013 15:13:28 +0100
Juri Lelli <juri.lelli@...il.com> wrote:
;
> >> +
> >> +#ifdef CONFIG_SMP
> >> +	/* zero means no -deadline tasks */
> > 
> > I'm curious to why you add the '-' to -deadline.
> > 
> 
> I guess "deadline tasks" is too much generic; "SCHED_DEADLINE tasks" too long;
> "DL" or "-dl" can be associated to "download". Nothing special in the end, just
> tought it was a reasonable abbreviation.

Yeah, keep the -deadline, as that makes it more searchable.

> >> +static int latest_cpu_find(struct cpumask *span,
> >> +			   struct task_struct *task,
> >> +			   struct cpumask *later_mask)
> >> +{
> >> +	const struct sched_dl_entity *dl_se = &task->dl;
> >> +	int cpu, found = -1, best = 0;
> >> +	u64 max_dl = 0;
> >> +
> >> +	for_each_cpu(cpu, span) {
> >> +		struct rq *rq = cpu_rq(cpu);
> >> +		struct dl_rq *dl_rq = &rq->dl;
> >> +
> >> +		if (cpumask_test_cpu(cpu, &task->cpus_allowed) &&
> >> +		    (!dl_rq->dl_nr_running || dl_time_before(dl_se->deadline,
> >> +		     dl_rq->earliest_dl.curr))) {
> >> +			if (later_mask)
> >> +				cpumask_set_cpu(cpu, later_mask);
> >> +			if (!best && !dl_rq->dl_nr_running) {
> >> +				best = 1;
> >> +				found = cpu;
> >> +			} else if (!best &&
> >> +				   dl_time_before(max_dl,
> >> +						  dl_rq->earliest_dl.curr)) {
> > 
> > Ug, the above is hard to read. What about:
> > 
> > 	if (!best) {
> > 		if (!dl_rq->dl_nr_running) {
> > 			best = 1;
> > 			found = cpu;
> > 		} elsif (dl_time_before(...)) {
> > 			...
> > 		}
> > 	}
> > 
> 
> This is completely removed in 13/14. I don't like it either, but since we end
> up removing this mess, do you think we still have to fix this here?

OK, if it gets removed later (I haven't hit patch 13 yet), then it
should be fine.

> 
> > Also, I would think dl should be nice to rt as well. There may be a
> > idle CPU or a non rt task, and this could pick a CPU running an RT
> > task. Worse yet, that RT task may be pinned to that CPU.
> > 
> 
> Well, in 13/14 we introduce a free_cpus mask. A CPU is considered free if it
> doesn't have any -deadline task running. We can modify that excluding also CPUs
> running RT tasks, but I have to think a bit if we can do this also from -rt code.
> 
> > We should be able to incorporate cpuprio_find() to be dl aware too.
> > That is, work for both -rt and -dl.
> >
> 
> Like checking if a -dl task is running on the cpu chosen for pushing an -rt
> task, and continue searching in that case.

Yep, and also, it could perhaps be used for knowing where to push a
-dl task too.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/