linux-kernel - Re: [PATCH] sched: avoid overpull when pulling RT task

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 15 May 2011 08:35:16 +0200
From:	Mike Galbraith <efault@....de>
To:	Hillf Danton <dhillf@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Yong Zhang <yong.zhang0@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] sched: avoid overpull when pulling RT task

On Sun, 2011-05-15 at 12:35 +0800, Hillf Danton wrote:
> When pulling RT task for a given runqueue, pulling is continued even
> after certain RT tasks get pulled, in case there are still higher
> priority tasks on other runqueues, though it is low likelihood as the
> comment says. The load of of this runqueue, on other hand, should also
> be concerned. If it is overloaded, the low likelihood should be
> abandoned to avoid overpull.
> 
> Signed-off-by: Hillf Danton <dhillf@...il.com>
> ---
>  kernel/sched_rt.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
> index 14c764b..b425ca1 100644
> --- a/kernel/sched_rt.c
> +++ b/kernel/sched_rt.c
> @@ -1508,6 +1508,11 @@ static int pull_rt_task(struct rq *this_rq)
>  		}
>  skip:
>  		double_unlock_balance(this_rq, src_rq);
> +
> +		/* if pulled we have to also avoid overpull */
> +		if (ret == 1)
> +			if (likely(rt_overloaded(this_rq)))
> +				break;
>  	}
> 
>  	return ret;

Hm.

It looks to me like you should remove the rt_overloaded() test (and
function) entirely instead.  If you look at pull usage, the intent is
that system wide, higher priority tasks run before lower.

I don't think it matters much if we pull too much, since what we pull
while traversing is ever increasing in priority _and waiting_ anyway.
We may do a bit more work than strictly necessary on the way to the
highest priority runnable task, but what matters most is that highest
priority gets to the CPU first, which testing for overload can stymie.

(seems pulling more than one could turn out either good or bad for any
but the highest priority task though, lacking crystal ball)

	-Mike

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