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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
