All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Linus Walleij <linus.ml.walleij@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	Lennart Poettering <lennart@poettering.net>,
	stable@kernel.org
Subject: Re: [PATCH] sched: SCHED_RESET_ON_FORK to recalculate load weights
Date: Mon, 11 Oct 2010 09:20:41 +0200	[thread overview]
Message-ID: <1286781641.2336.63.camel@twins> (raw)
In-Reply-To: <AANLkTi=JfJknPNMiMXnK=kZj+ECJTE423AfjuiE67afu@mail.gmail.com>

On Mon, 2010-10-11 at 01:05 +0200, Linus Walleij wrote:
> 2010/10/9 Peter Zijlstra <peterz@infradead.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?

  reply	other threads:[~2010-10-11  7:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-09  8:16 [PATCH] sched: SCHED_RESET_ON_FORK to recalculate load weights Linus Walleij
2010-10-09 15:53 ` Peter Zijlstra
2010-10-10 23:05   ` Linus Walleij
2010-10-11  7:20     ` Peter Zijlstra [this message]
2010-10-11 14:38       ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1286781641.2336.63.camel@twins \
    --to=peterz@infradead.org \
    --cc=lennart@poettering.net \
    --cc=linus.ml.walleij@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.