linux-kernel - Re: [PATCH v2] sched/deadline: remove useless param from setup_new_dl

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]

Date:	Tue, 5 Jul 2016 17:58:30 +0100
From:	Juri Lelli <juri.lelli@....com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	peterz@...radead.org, linux-kernel@...r.kernel.org,
	mingo@...hat.com, luca.abeni@...tn.it
Subject: Re: [PATCH v2] sched/deadline: remove useless param from
 setup_new_dl_entity

On 05/07/16 12:47, Steven Rostedt wrote:
> On Tue, 5 Jul 2016 15:39:33 +0100
> Juri Lelli <juri.lelli@....com> wrote:
> 
> 		return;
> > > >  
> > > >  	/*
> > > > +	 * Use the scheduling parameters of the top pi-waiter task,
> > > > +	 * if we have one from which we can inherit a deadline.
> > > > +	 */
> > > > +	if (pi_task && dl_se->dl_boosted && dl_prio(pi_task->normal_prio))
> > > > +		pi_se = &pi_task->dl;
> > > > +  
> > > 
> > > OK, I'm micro-optimizing now, but hey, isn't this a fast path?
> > > 
> > > What about changing the above to:
> > > 
> > > 	struct task_struct *pi_task;
> > > 	[...]
> > > 
> > > 	if (dl_se->dl_boosted && dl_prio(pi_task->normal_prio &&  
> >                                     ^
> > OK, we need to reorder these two
> >                                     V
> > > 	    (pi_task = rt_mutex_get_top_task(dl_task_of(dl_se)))
> > > 		pe_se = &pi_task->dl;
> 
> Opps, you're right.
> 
> > > 
> > > This way we don't need to do any work of looking at
> > > rt_mutex_get_top_task() for the normal case.
> > >   
> > 
> > But, yes. Looks good to me. I'll shoot a v3 ASAP.
> 
> I have to ask, should there be any check if the dl_se has a shorter
> deadline than the pi one?
> 

Yeah. I wondered the same actually. I convinced myself that, since the
task is boosted, we assume that the donor will have a shorter deadline.
We seem to be doing the same elsewhere, but Luca was saying some time
ago that the DI thing my have some problems and needs to be revised.
Is is fair enough fixing this bit in accordance with the current (maybe
broken) behaviour and then spend time reviewing the whole thing, or do
we want to do both at the same time (which will of course require more
time)?

Best,

- Juri