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: <20160705165829.GN17689@e106622-lin>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ