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] [day] [month] [year] [list]
Date:	Sun, 22 Apr 2012 11:48:10 +0200
From:	Juri Lelli <juri.lelli@...il.com>
To:	Hillf Danton <dhillf@...il.com>
CC:	Dario Faggioli <raistlin@...ux.it>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] DLS: cleanup pulling task

Hi Hillf,
sorry for a so delayed replay, but I was really busy in the last
two weeks.

Before going inline I would anyway stress the point that we tried
to be as much aligned as we could with sched_rt.c. This is a
design choice and the reason behind is simple: -rt is highly
tested and verified. Since conceptually -dl doesn't differ to much
from -rt, beeing based on it allows two things:
    - try to not incur in known design flaws/bugs
    - exploit the community work on -rt for -dl benefit (patches on
      -rt can be quite straightforwardly applied to -dl)

However, this doesn't mean that both codes are immutable, only that
changes in -rt must be well documented to be applied and we would
like to take advantage of this work in an indirect way as much as
we can. At the same time we are also playing with the push/pull
mechanism, so I can understand your interest :-P.

And now to your proposed changes :-)...

On 04/07/2012 12:14 PM, Hillf Danton wrote:
> First add check for CPU online.
> Second initialize dmin to be as min as possible.
> Third, the preempt check is not available yet=(
>
> Due to re-init of dmin, a couple of preempt checks are removed.
>
> With runqueue lock, a couple of caution checks are also removed.
>
> Finally the jumple lable, skip, is replaced with unlock.
>
> Signed-off-by: Hillf Danton<dhillf@...il.com>
> ---
>
> --- a/kernel/sched_dl.c	Sat Apr  7 15:00:28 2012
> +++ b/kernel/sched_dl.c	Sat Apr  7 17:33:44 2012
> @@ -1287,71 +1287,53 @@ static void push_dl_tasks(struct rq *rq)
>
>   static int pull_dl_task(struct rq *this_rq)
>   {
> -	int this_cpu = this_rq->cpu, ret = 0, cpu;
> -	struct task_struct *p;
> -	struct rq *src_rq;
> -	u64 dmin = LONG_MAX;
> +	int this_cpu = this_rq->cpu;
> +	int cpu;
> +	u64 dmin;
> +	int ret = 0;
>
>   	if (likely(!dl_overloaded(this_rq)))
>   		return 0;
>
> -	for_each_cpu(cpu, this_rq->rd->dlo_mask) {
> +	if (this_rq->dl.dl_nr_running)
> +		dmin = this_rq->dl.earliest_dl.curr;
> +	else
> +		dmin = -1ULL;
> +

Below we potentially drop this_rq->lock. In the original code we
update dmin only with both locks, it is probably more consistent.

> +	for_each_cpu_and(cpu, this_rq->rd->dlo_mask, cpu_online_mask) {

dlo_mask is updated every time a cpu goes on/off, so this check should
be implicit.

> +		struct task_struct *p;
> +		struct rq *src_rq;
> +
>   		if (this_cpu == cpu)
>   			continue;
>
>   		src_rq = cpu_rq(cpu);
>
> -		/*
> -		 * It looks racy, abd it is! However, as in sched_rt.c,
> -		 * we are fine with this.
> -		 */
> -		if (this_rq->dl.dl_nr_running&&
> -		    dl_time_before(this_rq->dl.earliest_dl.curr,
> -				   src_rq->dl.earliest_dl.next))
> +		/* Racy without runqueue lock, but we are fine now */

Doesn't seem this changes much regarding locks. Why you say we are
fine?

> +		if (!dl_time_before(src_rq->dl.earliest_dl.next, dmin))
>   			continue;
>
> -		/* Might drop this_rq->lock */
>   		double_lock_balance(this_rq, src_rq);
>
> -		/*
> -		 * If there are no more pullable tasks on the
> -		 * rq, we're done with it.
> -		 */
>   		if (src_rq->dl.dl_nr_running<= 1)
> -			goto skip;
> +			goto unlock;
>
>   		p = pick_next_earliest_dl_task(src_rq, this_cpu);
>
> -		/*
> -		 * We found a task to be pulled if:
> -		 *  - it preempts our current (if there's one),
> -		 *  - it will preempt the last one we pulled (if any).
> -		 */
> -		if (p&&  dl_time_before(p->dl.deadline, dmin)&&
> -		    (!this_rq->dl.dl_nr_running ||
> -		     dl_time_before(p->dl.deadline,
> -				    this_rq->dl.earliest_dl.curr))) {
> -			WARN_ON(p == src_rq->curr);
> -			WARN_ON(!p->on_rq);
> -
> -			/*
> -			 * Then we pull iff p has actually an earlier
> -			 * deadline than the current task of its runqueue.
> -			 */
> -			if (dl_time_before(p->dl.deadline,
> -					   src_rq->curr->dl.deadline))
> -				goto skip;
> +		/* With runqueue lock, recheck preempty */
> +		if (p&&  dl_time_before(p->dl.deadline, dmin)) {
>
> -			ret = 1;
> +			/* We dont pull running task */
> +			if (p == src_rq->curr)
> +				goto unlock;

This should be the case with pick_next_earliest_dl_task, we in fact check
that this is true with the WARN_ON.

>
>   			deactivate_task(src_rq, p, 0);
>   			set_task_cpu(p, this_cpu);
>   			activate_task(this_rq, p, 0);
> +			ret++;
>   			dmin = p->dl.deadline;
> -
> -			/* Is there any other task even earlier? */
>   		}
> -skip:
> +unlock:
>   		double_unlock_balance(this_rq, src_rq);
>   	}
>
> --

Thanks a lot for your interest in the patchset!

Cheers,

- Juri
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ