[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.20.1705302155400.17440@knanqh.ubzr>
Date: Tue, 30 May 2017 22:18:16 -0400 (EDT)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: Peter Zijlstra <peterz@...radead.org>
cc: Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 6/7] sched/rt: make it configurable
On Tue, 30 May 2017, Peter Zijlstra wrote:
> On Tue, May 30, 2017 at 08:17:00AM -0400, Nicolas Pitre wrote:
> > On Tue, 30 May 2017, Peter Zijlstra wrote:
> >
> > > On Mon, May 29, 2017 at 05:03:01PM -0400, Nicolas Pitre wrote:
> > >
> > > > @@ -1303,8 +1303,17 @@ config SCHED_AUTOGROUP
> > > > desktop applications. Task group autogeneration is currently based
> > > > upon task session.
> > > >
> > > > +config SCHED_RT
> > > > + bool "Real Time Task Scheduling" if EXPERT
> > > > + default y
> > > > + help
> > > > + This adds the sched_rt scheduling class to the kernel providing
> > > > + support for the SCHED_FIFO and SCHED_RR policies. You might want
> > > > + to disable this to reduce the kernel size. If unsure say y.
> > > > +
> > > > config SCHED_DL
> > > > bool "Deadline Task Scheduling" if EXPERT
> > > > + depends on SCHED_RT
> > > > default y
> > > > help
> > > > This adds the sched_dl scheduling class to the kernel providing
> > > > @@ -1632,6 +1641,7 @@ config BASE_FULL
> > > > config FUTEX
> > > > bool "Enable futex support" if EXPERT
> > > > default y
> > > > + depends on SCHED_RT
U> > > > Disabling this option will cause the kernel to be
built without
> > >
> > > Aside from all the other completely non-starter #ifdeffery trainwrecks,
> > > this is just plain wrong.
> >
> > Care to elaborate?
>
> SCHED_DL does not in any way depend on SCHED_RT
After a second look, the actual dependencies are very thin, so that's
easy to care for.
> and futexes should not
> wholly get axed when we lack SCHED_RT.
Indeed, only PI futexes depend on rt_mutexes. Will fix.
> > You might not like the approach, but you can't dismiss the goal just
> > like that. So please help me do it right.
>
> Why can't I dismiss it? All I see is ugly that makes maintenance worse
> for very little to no benefit.
Maybe there is no benefits to you and your use cases. But don't we want
for the embedded crowd to get more involved with mainline?
I didn't like the #ifdefery myself, but I wanted to put those patches
out early for comments. I'm grateful you provided yours and that they
highlight things that look relatively easy to address.
Nicolas
Powered by blists - more mailing lists