linux-kernel - Re: [RFC v2 4/7] Fix the update of the total -deadline utilization

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 Apr 2016 19:16:19 +0200
From:	luca abeni <luca.abeni@...tn.it>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Juri Lelli <juri.lelli@....com>
Subject: Re: [RFC v2 4/7] Fix the update of the total -deadline utilization

Hi Peter,

On Tue, 5 Apr 2016 14:58:59 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Fri, Apr 01, 2016 at 05:12:30PM +0200, Luca Abeni wrote:
> > +		/*
> > +		 * XXX this is slightly incorrect: when the task
> > +		 * utilization decreases, we should delay the total
> > +		 * utilization change until the task's 0-lag point.
> > +		 * But this would require to set the task's "inactive
> > +		 * timer" when the task is not inactive.
> > +		 */
> 
> Could you quickly remind me why this is a problem?

Do you mean, why it is a problem to activate the "inactive timer"
when the task is inactive?
I designed inactive_task_timer() to be executed when the task is not
active (for example, if the task's state is TASK_RUNNING inactive_task_timer()
returns without doing anything).
One problem could be that inactive_task_timer() decreases the utilisation of
the task's rq (I am beginning to wonder if using the task's rq instead of the
rq of the CPU on which the timer is running is a good idea, BTW); if the task
is running, it can migrate to a different rq and inactive_task_timer() will
decrease the wrong utilisation.

Or do you mean why updating the utilisation now is a problem?
This is slightly incorrect because decreasing the utilisation too early we
risk to admit tasks that create a transient overload (with some unexpected
deadline misses).

Or did I misunderstand your question?

				Thanks,
					Luca

> The timeline does
> continue running right? So even if the task isn't active now, it will
> still reach its 0-lag point.