Re: [PATCH] sched: Support compiling out real-time scheduling withREALTIME_SCHED.

[Josh Triplett]

On Wed, Aug 15, 2012 at 09:12:20AM +0200, Mike Galbraith wrote:
> On Tue, 2012-08-14 at 13:50 -0700, Trevor Brandt wrote:
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 3f42cd6..768dc76 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -27,6 +27,13 @@ config IRQ_WORK
> >  	bool
> >  	depends on HAVE_IRQ_WORK
> >  
> > +config REALTIME_SCHED
> > +	bool "Realtime Scheduler" if EXPERT
> > +	default y
> > +	help
> > +	  This option enables support for the realtime scheduler and the
> > +	  corresponding scheduling classes SCHED_FIFO and SCHED_RR.
> > +
> >  menu "General setup"
> >  
> >  config EXPERIMENTAL
> 
> If you inverted that, it could be a proper default n new feature [1].

Huh.  You mean, DISABLE_REALTIME_SCHED?  How would that help?
DISABLE_REALTIME_SCHED=n seems like an unnecessary double negative, and
I see very little precedent for that in Kconfig options.

> (that SMP could select to greatly simplify RT)

I hope this isn't a serious suggestion. :)  In any case, that doesn't
seem like something that should happen in *this* patch, if it should
happen at all.

> However, if weight loss is the goal, why not go whole hog, and create
> sched/thin.c containing no lard... or just integrate an existing thin
> scheduler as a config option?

Historically, the response to configurable/modular/selectable schedulers
has been entirely negative, with most responses amounting to "we should
fix the scheduler we have to work for all workloads", which doesn't seem
like an unreasonable response to me.

The kernel also has a *large* number of dependencies on the workings of
the fair scheduler, and as this patch shows, far fewer on the real-time
scheduler.

Given both of the above, writing and integrating an entirely new
scheduler (*and* dealing with the repeats of old flamewars that would
ensue after posting it) seems a bit much to ask for a student project.
:)

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/