From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Brian Silverman <brian@peloton-tech.com>,
linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org,
bigeasy@linutronix.de, Ingo Molnar <mingo@kernel.org>,
Mike Galbraith <umgwanakikbuti@gmail.com>
Subject: Re: [PATCH] Force processes to non-realtime before mm_exit
Date: Fri, 2 Sep 2016 17:02:29 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1609021700530.5647@nanos> (raw)
In-Reply-To: <20160714172429.GH30935@twins.programming.kicks-ass.net>
On Thu, 14 Jul 2016, Peter Zijlstra wrote:
> On Fri, Jun 03, 2016 at 04:18:44PM -0700, Brian Silverman wrote:
> > Without this, a realtime process which has called mlockall exiting
> > causes large latencies for other realtime processes at the same or
> > lower priorities. This seems like a fairly common use case too, because
> > realtime processes generally want their memory locked into RAM.
>
> So I'm not too sure.. SCHED_FIFO/RR are a complete trainwreck and
> provide absolutely no isolation from badly behaving tasks what so ever,
> so I'm not too inclined to protect them from exit either, its just one
> more way in which they can cause pain.
>
> But aside from the, the patch has issues..
>
> > +++ b/kernel/exit.c
> > @@ -730,6 +730,12 @@ void do_exit(long code)
> > tsk->exit_code = code;
> > taskstats_exit(tsk, group_dead);
> >
> > + if (tsk->policy == SCHED_FIFO || tsk->policy == SCHED_RR) {
> > + struct sched_param param = { .sched_priority = 0 };
> > +
> > + sched_setscheduler_nocheck(current, SCHED_NORMAL, ¶m);
> > + }
> > +
> > exit_mm(tsk);
>
> That only does half a job. You forget about SCHED_DEADLINE and negative
> nice tasks.
>
> Something like the below perhaps... But yeah, unconvinced.
I agree that FIFO/RR can cause pain, but running exit_mm() with RT priority
or consuming DL time is silly.
FWIW: Acked-by-me
next prev parent reply other threads:[~2016-09-02 15:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-03 23:18 [PATCH] Force processes to non-realtime before mm_exit Brian Silverman
2016-06-05 0:28 ` Corey Minyard
2016-07-14 17:24 ` Peter Zijlstra
2016-09-02 15:02 ` Thomas Gleixner [this message]
[not found] <1462903464-11448-1-git-send-email-brian@peloton-tech.com>
[not found] ` <20160512085946.GB19035@linutronix.de>
[not found] ` <CAGt3f4m=+yimx-wxDjH9TCzAb5F6zUbxG_RAEhTrT4cZWFKKcg@mail.gmail.com>
[not found] ` <20160525163323.GB18036@linutronix.de>
[not found] ` <CAGt3f4=SyBqM-7Jeitx10Tm8yTrNBpSoFNvCZNZX7A3oixzUzA@mail.gmail.com>
[not found] ` <574602F0.2070608@linutronix.de>
2016-06-03 23:33 ` Brian Silverman
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=alpine.DEB.2.20.1609021700530.5647@nanos \
--to=tglx@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=brian@peloton-tech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=umgwanakikbuti@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).