linux-kernel - Re: [PATCH] sched: SCHED_RESET_ON_FORK to recalculate load weights

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:	Mon, 11 Oct 2010 09:20:41 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Linus Walleij <linus.ml.walleij@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Lennart Poettering <lennart@...ttering.net>, stable@...nel.org
Subject: Re: [PATCH] sched: SCHED_RESET_ON_FORK to recalculate load weights

On Mon, 2010-10-11 at 01:05 +0200, Linus Walleij wrote:
> 2010/10/9 Peter Zijlstra <peterz@...radead.org>:
> 
> > On Sat, 2010-10-09 at 10:16 +0200, Linus Walleij wrote:
> >>
> >> So we always need to call set_load_weight(), not just if the
> >> niceval was changed, because the scheduler gives
> >> SCHED_RR/SCHED_FIFO processes very high weights.
> >
> > SCHED_RR/FIFO never uses that weight, we should remove all that cruft..
> 
> Hm I wonder if that is an ACK or "please throughly rewrite the
> scheduler" request ;-)

Nah, its an SCHED_FIFO/RR shouldn't care about p->se.load at all
statement, any patch that mentions that relation cannot be right ;-)

> Anyway I also saw you have started to get rid of RT weights it in
> commit e51fd5e2, so in set_load_weight():
> 
>        if (task_has_rt_policy(p)) {
>                 p->se.load.weight = prio_to_weight[0] * 2;
>                 p->se.load.inv_weight = prio_to_wmult[0] >> 1;
>                 return;
>         }
> 
> is now replaced by this:
> 
>         if (task_has_rt_policy(p)) {
>                 p->se.load.weight = 0;
>                 p->se.load.inv_weight = WMULT_CONST;
>                 return;
>         }

Right, that was to catch anybody relying on RR/FIFO tasks having a
sensible weight, I think we can now simply remove that whole clause.

> I backported that commit onto 2.6.34 (bah, just patch -p1)
> and tested. The problem persists, but mutates:

/me fails to see the relevance to .34 (or for that matter remember
what .34 looked like).

> Whereas before this commit the problem was that processes came
> back with enormous weights after forking of an RT process flagged
> with SCHED_RESET_ON_FORK, the problem is now the reverse:
> the process comes back with load weight zero making the forked
> process totally numb (when it has enormous weights it would atlest
> respond), so this patch is still needed to bring the weight back in
> balance AFAICT.

OK, so the problem is that if a RR/FIFO task does s fork() and it has
SCHED_RESET_ON_FORK set, the child normalization fails to properly set
the weight?

Does (as Mike just suggested) removing that whole RT clause in
set_load_weight() work for you?
--
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/