| Message ID | 1452288166-43501-3-git-send-email-jonathan.creekmore@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 08/01/16 21:22, Jonathan Creekmore wrote: > +# Enable schedulers > +menu "Schedulers" > + visible if EXPERT = "y" > + > +config SCHED_CREDIT > + bool "Credit scheduler support" > + default y > + ---help--- > + The traditional credit scheduler is a general purpose scheduler. > + > + If unsure, say Y. > + > +config SCHED_CREDIT2 > + bool "Credit2 scheduler support (EXPERIMENTAL)" > + default y > + ---help--- > + The credit2 scheduler is a general purpose scheduler that is > + optimized for lower latency and higher VM density. > + > + If unsure, say Y. > + > +config SCHED_RTDS > + bool "RTDS scheduler support (EXPERIMENTAL)" > + default y > + ---help--- > + The RTDS scheduler is a soft and firm real-time scheduler for > + multicore, targeted for embedded, automotive, graphics and gaming > + in the cloud, and general low-latency workloads. > + > + If unsure, say N. > + > +config SCHED_ARINC653 > + bool "ARINC653 scheduler support (EXPERIMENTAL)" > + default y > + ---help--- > + The ARINC653 scheduler is a hard real-time scheduler for single > + cores, targeted for avionics, drones, and medical devices. > + > + If unsure, say N. Sorry for not noticing this before. The "If unsure, say $X" should really match the default value. On the other hand, given that we are hiding all these options behind CONFIG_EXPERT, I am not sure that we need "If unsure" clauses. Anyone who isn't sure shouldn't have turned on CONFIG_EXPERT to start with. ~Andrew
Andrew Cooper writes: > On 08/01/16 21:22, Jonathan Creekmore wrote: >> +# Enable schedulers >> +menu "Schedulers" >> + visible if EXPERT = "y" >> + >> +config SCHED_CREDIT >> + bool "Credit scheduler support" >> + default y >> + ---help--- >> + The traditional credit scheduler is a general purpose scheduler. >> + >> + If unsure, say Y. >> + >> +config SCHED_CREDIT2 >> + bool "Credit2 scheduler support (EXPERIMENTAL)" >> + default y >> + ---help--- >> + The credit2 scheduler is a general purpose scheduler that is >> + optimized for lower latency and higher VM density. >> + >> + If unsure, say Y. >> + >> +config SCHED_RTDS >> + bool "RTDS scheduler support (EXPERIMENTAL)" >> + default y >> + ---help--- >> + The RTDS scheduler is a soft and firm real-time scheduler for >> + multicore, targeted for embedded, automotive, graphics and gaming >> + in the cloud, and general low-latency workloads. >> + >> + If unsure, say N. >> + >> +config SCHED_ARINC653 >> + bool "ARINC653 scheduler support (EXPERIMENTAL)" >> + default y >> + ---help--- >> + The ARINC653 scheduler is a hard real-time scheduler for single >> + cores, targeted for avionics, drones, and medical devices. >> + >> + If unsure, say N. > > Sorry for not noticing this before. The "If unsure, say $X" should > really match the default value. > > On the other hand, given that we are hiding all these options behind > CONFIG_EXPERT, I am not sure that we need "If unsure" clauses. Anyone > who isn't sure shouldn't have turned on CONFIG_EXPERT to start with. I was trying to mimic language that the Linux kernel would use for EXPERIMENTAL marked items. Given the documentation on the wiki, I think marking those three schedulers EXPERIMENTAL is correct. Given that, I still think that the language saying "If unsure, say N" is correct (the thought being, the only people who should be messing with the EXPERIMENTAL schedulers are people developing or specifically testing them). The *only* reason I marked them default of Y is to keep backwards compatibility with the current build. However, if you would prefer me to remove the "If unsure" language completely, I can do that. The text came in before the whole CONFIG_EXPERT flag did.
On 09/01/16 17:50, Jonathan Creekmore wrote: > Andrew Cooper writes: > >> On 08/01/16 21:22, Jonathan Creekmore wrote: >>> +# Enable schedulers >>> +menu "Schedulers" >>> + visible if EXPERT = "y" >>> + >>> +config SCHED_CREDIT >>> + bool "Credit scheduler support" >>> + default y >>> + ---help--- >>> + The traditional credit scheduler is a general purpose scheduler. >>> + >>> + If unsure, say Y. >>> + >>> +config SCHED_CREDIT2 >>> + bool "Credit2 scheduler support (EXPERIMENTAL)" >>> + default y >>> + ---help--- >>> + The credit2 scheduler is a general purpose scheduler that is >>> + optimized for lower latency and higher VM density. >>> + >>> + If unsure, say Y. >>> + >>> +config SCHED_RTDS >>> + bool "RTDS scheduler support (EXPERIMENTAL)" >>> + default y >>> + ---help--- >>> + The RTDS scheduler is a soft and firm real-time scheduler for >>> + multicore, targeted for embedded, automotive, graphics and gaming >>> + in the cloud, and general low-latency workloads. >>> + >>> + If unsure, say N. >>> + >>> +config SCHED_ARINC653 >>> + bool "ARINC653 scheduler support (EXPERIMENTAL)" >>> + default y >>> + ---help--- >>> + The ARINC653 scheduler is a hard real-time scheduler for single >>> + cores, targeted for avionics, drones, and medical devices. >>> + >>> + If unsure, say N. >> Sorry for not noticing this before. The "If unsure, say $X" should >> really match the default value. >> >> On the other hand, given that we are hiding all these options behind >> CONFIG_EXPERT, I am not sure that we need "If unsure" clauses. Anyone >> who isn't sure shouldn't have turned on CONFIG_EXPERT to start with. > I was trying to mimic language that the Linux kernel would use for > EXPERIMENTAL marked items. Given the documentation on the wiki, I think > marking those three schedulers EXPERIMENTAL is correct. I concur about their status. > Given that, I > still think that the language saying "If unsure, say N" is correct (the > thought being, the only people who should be messing with the > EXPERIMENTAL schedulers are people developing or specifically testing > them). The *only* reason I marked them default of Y is to keep backwards > compatibility with the current build. Also very important. > > However, if you would prefer me to remove the "If unsure" language > completely, I can do that. The text came in before the whole > CONFIG_EXPERT flag did. I would suggest dropping it (although you probably want to wait for opinions from others). We have already diverged from Linux with regards to the EXPERT flag; people who are unsure cannot accidentally get here. ~Andrew
Andrew Cooper writes: > On 09/01/16 17:50, Jonathan Creekmore wrote: >> Andrew Cooper writes: >> >>> On 08/01/16 21:22, Jonathan Creekmore wrote: >>>> +# Enable schedulers >>>> +menu "Schedulers" >>>> + visible if EXPERT = "y" >>>> + >>>> +config SCHED_CREDIT >>>> + bool "Credit scheduler support" >>>> + default y >>>> + ---help--- >>>> + The traditional credit scheduler is a general purpose scheduler. >>>> + >>>> + If unsure, say Y. >>>> + >>>> +config SCHED_CREDIT2 >>>> + bool "Credit2 scheduler support (EXPERIMENTAL)" >>>> + default y >>>> + ---help--- >>>> + The credit2 scheduler is a general purpose scheduler that is >>>> + optimized for lower latency and higher VM density. >>>> + >>>> + If unsure, say Y. >>>> + >>>> +config SCHED_RTDS >>>> + bool "RTDS scheduler support (EXPERIMENTAL)" >>>> + default y >>>> + ---help--- >>>> + The RTDS scheduler is a soft and firm real-time scheduler for >>>> + multicore, targeted for embedded, automotive, graphics and gaming >>>> + in the cloud, and general low-latency workloads. >>>> + >>>> + If unsure, say N. >>>> + >>>> +config SCHED_ARINC653 >>>> + bool "ARINC653 scheduler support (EXPERIMENTAL)" >>>> + default y >>>> + ---help--- >>>> + The ARINC653 scheduler is a hard real-time scheduler for single >>>> + cores, targeted for avionics, drones, and medical devices. >>>> + >>>> + If unsure, say N. >>> Sorry for not noticing this before. The "If unsure, say $X" should >>> really match the default value. >>> >>> On the other hand, given that we are hiding all these options behind >>> CONFIG_EXPERT, I am not sure that we need "If unsure" clauses. Anyone >>> who isn't sure shouldn't have turned on CONFIG_EXPERT to start with. >> I was trying to mimic language that the Linux kernel would use for >> EXPERIMENTAL marked items. Given the documentation on the wiki, I think >> marking those three schedulers EXPERIMENTAL is correct. > > I concur about their status. > >> Given that, I >> still think that the language saying "If unsure, say N" is correct (the >> thought being, the only people who should be messing with the >> EXPERIMENTAL schedulers are people developing or specifically testing >> them). The *only* reason I marked them default of Y is to keep backwards >> compatibility with the current build. > > Also very important. > >> >> However, if you would prefer me to remove the "If unsure" language >> completely, I can do that. The text came in before the whole >> CONFIG_EXPERT flag did. > > I would suggest dropping it (although you probably want to wait for > opinions from others). We have already diverged from Linux with regards > to the EXPERT flag; people who are unsure cannot accidentally get here. OK, if I haven't heard anything from any others by the time I send out my v5 on Monday with the other items you caught, then I will go ahead and remove the language.
>>> On 09.01.16 at 19:08, <andrew.cooper3@citrix.com> wrote: > On 09/01/16 17:50, Jonathan Creekmore wrote: >> However, if you would prefer me to remove the "If unsure" language >> completely, I can do that. The text came in before the whole >> CONFIG_EXPERT flag did. > > I would suggest dropping it (although you probably want to wait for > opinions from others). We have already diverged from Linux with regards > to the EXPERT flag; people who are unsure cannot accidentally get here. +1 Jan
>>> On 08.01.16 at 22:22, <jonathan.creekmore@gmail.com> wrote: > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -51,4 +51,71 @@ config KEXEC > > If unsure, say Y. > > +# Enable schedulers > +menu "Schedulers" > + visible if EXPERT = "y" Does "visible if EXPERT" not suffice here? > +config SCHED_CREDIT > + bool "Credit scheduler support" > + default y I continue to think that not making the primary scheduler configurable would be the better solution to the problems resulting from possibly all of them getting turned off. > +config SCHED_CREDIT2 > + bool "Credit2 scheduler support (EXPERIMENTAL)" > + default y > + ---help--- > + The credit2 scheduler is a general purpose scheduler that is > + optimized for lower latency and higher VM density. > + > + If unsure, say Y. > + > +config SCHED_RTDS > + bool "RTDS scheduler support (EXPERIMENTAL)" > + default y > + ---help--- > + The RTDS scheduler is a soft and firm real-time scheduler for > + multicore, targeted for embedded, automotive, graphics and gaming > + in the cloud, and general low-latency workloads. > + > + If unsure, say N. > + > +config SCHED_ARINC653 > + bool "ARINC653 scheduler support (EXPERIMENTAL)" > + default y > + ---help--- > + The ARINC653 scheduler is a hard real-time scheduler for single > + cores, targeted for avionics, drones, and medical devices. > + > + If unsure, say N. > + > +choice > + prompt "Default Scheduler?" > + default SCHED_CREDIT_DEFAULT if SCHED_CREDIT > + default SCHED_CREDIT2_DEFAULT if SCHED_CREDIT2 > + default SCHED_RTDS_DEFAULT if SCHED_RTDS > + default SCHED_ARINC653_DEFAULT if SCHED_ARINC653 > + > + config SCHED_CREDIT_DEFAULT > + bool "Credit Scheduler" if SCHED_CREDIT > + config SCHED_CREDIT2_DEFAULT > + bool "Credit2 Scheduler" if SCHED_CREDIT2 > + config SCHED_RTDS_DEFAULT > + bool "RT Scheduler" if SCHED_RTDS > + config SCHED_ARINC653_DEFAULT > + bool "ARINC653 Scheduler" if SCHED_ARINC653 > +endchoice > + > +config SCHED_DEFAULT > + string > + default "credit" if SCHED_CREDIT_DEFAULT > + default "credit2" if SCHED_CREDIT2_DEFAULT > + default "rtds" if SCHED_RTDS_DEFAULT > + default "arinc653" if SCHED_ARINC653_DEFAULT > + default "credit" What use is this last line? > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -850,8 +850,13 @@ static inline bool_t is_vcpu_online(const struct vcpu *v) > return !test_bit(_VPF_down, &v->pause_flags); > } > > +#ifdef CONFIG_SCHED_CREDIT > void set_vcpu_migration_delay(unsigned int delay); > unsigned int get_vcpu_migration_delay(void); > +#else > +static inline void set_vcpu_migration_delay(unsigned int delay) { } > +static inline unsigned int get_vcpu_migration_delay(void) { return 0; } > +#endif I don't think these are appropriate: The respective sysctl sub-ops would probably better indicate failure to the caller. Jan
Jan Beulich writes: >>>> On 08.01.16 at 22:22, <jonathan.creekmore@gmail.com> wrote: >> --- a/xen/common/Kconfig >> +++ b/xen/common/Kconfig >> @@ -51,4 +51,71 @@ config KEXEC >> >> If unsure, say Y. >> >> +# Enable schedulers >> +menu "Schedulers" >> + visible if EXPERT = "y" > > Does "visible if EXPERT" not suffice here? No, because EXPERT is a string and not a boolean. It has to be a string since it is pulling in a string from the environment to set its value. > >> +config SCHED_CREDIT >> + bool "Credit scheduler support" >> + default y > > I continue to think that not making the primary scheduler configurable > would be the better solution to the problems resulting from possibly > all of them getting turned off. Except that is completely contrary to my goal with this patchset (being able to compile in just the scheduler that I want to use). Yes, at the moment, credit is the only non-experimental scheduler and will likely be the one we choose. However, in the future, when credit2 and possibly others are non-experimental, we may choose one of the other schedulers and do not want to carry along credit in our build just because it is the primary scheduler. > >> +config SCHED_CREDIT2 >> + bool "Credit2 scheduler support (EXPERIMENTAL)" >> + default y >> + ---help--- >> + The credit2 scheduler is a general purpose scheduler that is >> + optimized for lower latency and higher VM density. >> + >> + If unsure, say Y. >> + >> +config SCHED_RTDS >> + bool "RTDS scheduler support (EXPERIMENTAL)" >> + default y >> + ---help--- >> + The RTDS scheduler is a soft and firm real-time scheduler for >> + multicore, targeted for embedded, automotive, graphics and gaming >> + in the cloud, and general low-latency workloads. >> + >> + If unsure, say N. >> + >> +config SCHED_ARINC653 >> + bool "ARINC653 scheduler support (EXPERIMENTAL)" >> + default y >> + ---help--- >> + The ARINC653 scheduler is a hard real-time scheduler for single >> + cores, targeted for avionics, drones, and medical devices. >> + >> + If unsure, say N. >> + >> +choice >> + prompt "Default Scheduler?" >> + default SCHED_CREDIT_DEFAULT if SCHED_CREDIT >> + default SCHED_CREDIT2_DEFAULT if SCHED_CREDIT2 >> + default SCHED_RTDS_DEFAULT if SCHED_RTDS >> + default SCHED_ARINC653_DEFAULT if SCHED_ARINC653 >> + >> + config SCHED_CREDIT_DEFAULT >> + bool "Credit Scheduler" if SCHED_CREDIT >> + config SCHED_CREDIT2_DEFAULT >> + bool "Credit2 Scheduler" if SCHED_CREDIT2 >> + config SCHED_RTDS_DEFAULT >> + bool "RT Scheduler" if SCHED_RTDS >> + config SCHED_ARINC653_DEFAULT >> + bool "ARINC653 Scheduler" if SCHED_ARINC653 >> +endchoice >> + >> +config SCHED_DEFAULT >> + string >> + default "credit" if SCHED_CREDIT_DEFAULT >> + default "credit2" if SCHED_CREDIT2_DEFAULT >> + default "rtds" if SCHED_RTDS_DEFAULT >> + default "arinc653" if SCHED_ARINC653_DEFAULT >> + default "credit" > > What use is this last line? > When the scheduler menu is not visible, the choice selection does not cause a scheduler to be chosen. The last line forces credit to be the default if none of the _DEFAULT values are selected. It is purely an artifact of introducing the visibility option on the menu. It could be moved into the defaults section for the choice like this: + default SCHED_CREDIT_DEFAULT if SCHED_CREDIT + default SCHED_CREDIT2_DEFAULT if SCHED_CREDIT2 + default SCHED_RTDS_DEFAULT if SCHED_RTDS + default SCHED_ARINC653_DEFAULT if SCHED_ARINC653 + default SCHED_CREDIT_DEFAULT >> --- a/xen/include/xen/sched.h >> +++ b/xen/include/xen/sched.h >> @@ -850,8 +850,13 @@ static inline bool_t is_vcpu_online(const struct vcpu *v) >> return !test_bit(_VPF_down, &v->pause_flags); >> } >> >> +#ifdef CONFIG_SCHED_CREDIT >> void set_vcpu_migration_delay(unsigned int delay); >> unsigned int get_vcpu_migration_delay(void); >> +#else >> +static inline void set_vcpu_migration_delay(unsigned int delay) { } >> +static inline unsigned int get_vcpu_migration_delay(void) { return 0; } >> +#endif > > I don't think these are appropriate: The respective sysctl sub-ops > would probably better indicate failure to the caller. I can make that change if you want me to. As it stands now, the existing sysctl sub-ops are probably not doing the right thing since they are setting and getting this migration delay in the credit scheduler regardless of which scheduler is actually in use.
>>> On 11.01.16 at 16:10, <jonathan.creekmore@gmail.com> wrote: > Jan Beulich writes: >>>>> On 08.01.16 at 22:22, <jonathan.creekmore@gmail.com> wrote: >>> +config SCHED_CREDIT >>> + bool "Credit scheduler support" >>> + default y >> >> I continue to think that not making the primary scheduler configurable >> would be the better solution to the problems resulting from possibly >> all of them getting turned off. > > Except that is completely contrary to my goal with this patchset (being > able to compile in just the scheduler that I want to use). Yes, at the > moment, credit is the only non-experimental scheduler and will likely be > the one we choose. However, in the future, when credit2 and possibly > others are non-experimental, we may choose one of the other schedulers > and do not want to carry along credit in our build just because it is > the primary scheduler. I think we need to separate what we want as "upstream", and what your internal intentions are. Any gap between that would need to be taken care of by private patches you'd have to carry. As "upstream", I think not allowing the default scheduler to be turned off is quite reasonable an approach. >>> --- a/xen/include/xen/sched.h >>> +++ b/xen/include/xen/sched.h >>> @@ -850,8 +850,13 @@ static inline bool_t is_vcpu_online(const struct vcpu *v) >>> return !test_bit(_VPF_down, &v->pause_flags); >>> } >>> >>> +#ifdef CONFIG_SCHED_CREDIT >>> void set_vcpu_migration_delay(unsigned int delay); >>> unsigned int get_vcpu_migration_delay(void); >>> +#else >>> +static inline void set_vcpu_migration_delay(unsigned int delay) { } >>> +static inline unsigned int get_vcpu_migration_delay(void) { return 0; } >>> +#endif >> >> I don't think these are appropriate: The respective sysctl sub-ops >> would probably better indicate failure to the caller. > > I can make that change if you want me to. As it stands now, the existing > sysctl sub-ops are probably not doing the right thing since they are > setting and getting this migration delay in the credit scheduler > regardless of which scheduler is actually in use. Yes and no - it would still change / obtain the value for those parts of the system (CPU pools) where that scheduler is being used. That set may be empty, but the scheduler is still present, and hence the operations succeeding is a valid thing as long as that scheduler exists. This changes, though, if the scheduler doesn't get built anymore. (And not how the problem would go away altogether if credit wasn't configurable.) Jan
On 1/11/16 9:43 AM, Jan Beulich wrote: >>>> On 11.01.16 at 16:10, <jonathan.creekmore@gmail.com> wrote: >> Jan Beulich writes: >>>>>> On 08.01.16 at 22:22, <jonathan.creekmore@gmail.com> wrote: >>>> +config SCHED_CREDIT >>>> + bool "Credit scheduler support" >>>> + default y >>> >>> I continue to think that not making the primary scheduler configurable >>> would be the better solution to the problems resulting from possibly >>> all of them getting turned off. >> >> Except that is completely contrary to my goal with this patchset (being >> able to compile in just the scheduler that I want to use). Yes, at the >> moment, credit is the only non-experimental scheduler and will likely be >> the one we choose. However, in the future, when credit2 and possibly >> others are non-experimental, we may choose one of the other schedulers >> and do not want to carry along credit in our build just because it is >> the primary scheduler. > > I think we need to separate what we want as "upstream", and what > your internal intentions are. Any gap between that would need to be > taken care of by private patches you'd have to carry. > > As "upstream", I think not allowing the default scheduler to be turned > off is quite reasonable an approach. > My immediate reaction to this request is "special casing is bad" and that's what this is straight away. Special cases make the code worse and weaker as a whole. There are no internal intentions here. Our internal intentions are to use the credit scheduler. The intentions are for configurability of all the options and not just some of the options. The goal here is to be more inclusive of various downstreams and the goal of Kconfig being a means by which to support that? The idea here was to encourage more upstream participation and not less. I can hardly see how configurability for an extreme corner case that's very hidden away from the average user would be harmful to upstream. There have been a good deal number of different downstreams that have been encouraging of changes like this but it seems like you are fundamentally opposed. Which is plainly discouraging to people to attempt to engage upstream. At some point it becomes damaging to the Xen upstream where users are unable to get what they need/want out of Xen upstream without having to become their own downstreams and patching. Another example of this can be seen with modern Lenovo laptops that do not properly follow the EFI spec. I've seen numerous patches rejected with the comment of "tell Lenovo to fix their hardware". The result is users of Lenovo hardware walk away feeling that Xen is broken not their hardware.
>>> On 11.01.16 at 17:31, <cardoe@cardoe.com> wrote: > There have been a good deal number of different downstreams that have > been encouraging of changes like this but it seems like you are > fundamentally opposed. Which is plainly discouraging to people to > attempt to engage upstream. I could see such a reaction as being valid if I objected to any of the configurability changes, but I have a hard time following when I just ask for the default scheduler to not become configurable. Plus I'm not the only one involved in getting to a decision here, i.e. I can easily be overruled by other maintainers. > At some point it becomes damaging to the Xen upstream where users are > unable to get what they need/want out of Xen upstream without having to > become their own downstreams and patching. Another example of this can > be seen with modern Lenovo laptops that do not properly follow the EFI > spec. I've seen numerous patches rejected with the comment of "tell > Lenovo to fix their hardware". The result is users of Lenovo hardware > walk away feeling that Xen is broken not their hardware. Well, if you followed the discussion closely you may have noticed we already kind of agreed that using DMI based quirks would be an acceptable mechanism to help the situation. As to my objection to make Xen violate the EFI spec by default, I continue to think this would be a bad idea, and I don't recall any substantial comments from you proving this a bad position. And yes, I'm having difficulty accepting massive amounts of workarounds for various vendors' quirks (be it EFI related or other), but commonly I accept such if they can be proven to not negatively impact other systems / platforms. And yes, I sincerely believe that hardware vendors should do a better job in implementing their firmware, the more that they managed to screw up many things in the PC BIOS days already, and one would think (hope) they would learn from older mistakes. Since they don't, getting people to put some pressure on them is, I think, quite appropriate. Working out or accepting side effect free workarounds in parallel is of course not excluded. Jan
On 1/11/16 10:49 AM, Jan Beulich wrote: >>>> On 11.01.16 at 17:31, <cardoe@cardoe.com> wrote: >> There have been a good deal number of different downstreams that have >> been encouraging of changes like this but it seems like you are >> fundamentally opposed. Which is plainly discouraging to people to >> attempt to engage upstream. > > I could see such a reaction as being valid if I objected to any of > the configurability changes, but I have a hard time following when > I just ask for the default scheduler to not become configurable. > Plus I'm not the only one involved in getting to a decision here, i.e. > I can easily be overruled by other maintainers. > I really hate to use Linux as an example here since its a different project but I will anyway. Linux has a number of flags like this were you can remove the default. The compression algorithm, the CPU schedule, the I/O scheduler. So it doesn't seem that far fetched to allow that.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 046e257..db7411b 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -51,4 +51,71 @@ config KEXEC If unsure, say Y. +# Enable schedulers +menu "Schedulers" + visible if EXPERT = "y" + +config SCHED_CREDIT + bool "Credit scheduler support" + default y + ---help--- + The traditional credit scheduler is a general purpose scheduler. + + If unsure, say Y. + +config SCHED_CREDIT2 + bool "Credit2 scheduler support (EXPERIMENTAL)" + default y + ---help--- + The credit2 scheduler is a general purpose scheduler that is + optimized for lower latency and higher VM density. + + If unsure, say Y. + +config SCHED_RTDS + bool "RTDS scheduler support (EXPERIMENTAL)" + default y + ---help--- + The RTDS scheduler is a soft and firm real-time scheduler for + multicore, targeted for embedded, automotive, graphics and gaming + in the cloud, and general low-latency workloads. + + If unsure, say N. + +config SCHED_ARINC653 + bool "ARINC653 scheduler support (EXPERIMENTAL)" + default y + ---help--- + The ARINC653 scheduler is a hard real-time scheduler for single + cores, targeted for avionics, drones, and medical devices. + + If unsure, say N. + +choice + prompt "Default Scheduler?" + default SCHED_CREDIT_DEFAULT if SCHED_CREDIT + default SCHED_CREDIT2_DEFAULT if SCHED_CREDIT2 + default SCHED_RTDS_DEFAULT if SCHED_RTDS + default SCHED_ARINC653_DEFAULT if SCHED_ARINC653 + + config SCHED_CREDIT_DEFAULT + bool "Credit Scheduler" if SCHED_CREDIT + config SCHED_CREDIT2_DEFAULT + bool "Credit2 Scheduler" if SCHED_CREDIT2 + config SCHED_RTDS_DEFAULT + bool "RT Scheduler" if SCHED_RTDS + config SCHED_ARINC653_DEFAULT + bool "ARINC653 Scheduler" if SCHED_ARINC653 +endchoice + +config SCHED_DEFAULT + string + default "credit" if SCHED_CREDIT_DEFAULT + default "credit2" if SCHED_CREDIT2_DEFAULT + default "rtds" if SCHED_RTDS_DEFAULT + default "arinc653" if SCHED_ARINC653_DEFAULT + default "credit" + +endmenu + endmenu diff --git a/xen/common/Makefile b/xen/common/Makefile index 8ab15ba..29a5916 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -30,10 +30,10 @@ obj-y += rangeset.o obj-y += radix-tree.o obj-y += rbtree.o obj-y += rcupdate.o -obj-y += sched_credit.o -obj-y += sched_credit2.o -obj-y += sched_arinc653.o -obj-y += sched_rt.o +obj-$(CONFIG_SCHED_ARINC653) += sched_arinc653.o +obj-$(CONFIG_SCHED_CREDIT) += sched_credit.o +obj-$(CONFIG_SCHED_CREDIT2) += sched_credit2.o +obj-$(CONFIG_SCHED_RTDS) += sched_rt.o obj-y += schedule.o obj-y += shutdown.o obj-y += softirq.o diff --git a/xen/common/schedule.c b/xen/common/schedule.c index d121896..2f98a48 100644 --- a/xen/common/schedule.c +++ b/xen/common/schedule.c @@ -38,8 +38,8 @@ #include <public/sched.h> #include <xsm/xsm.h> -/* opt_sched: scheduler - default to credit */ -static char __initdata opt_sched[10] = "credit"; +/* opt_sched: scheduler - default to configured value */ +static char __initdata opt_sched[10] = CONFIG_SCHED_DEFAULT; string_param("sched", opt_sched); /* if sched_smt_power_savings is set, @@ -65,10 +65,18 @@ DEFINE_PER_CPU(struct schedule_data, schedule_data); DEFINE_PER_CPU(struct scheduler *, scheduler); static const struct scheduler *schedulers[] = { +#ifdef CONFIG_SCHED_CREDIT &sched_credit_def, +#endif +#ifdef CONFIG_SCHED_CREDIT2 &sched_credit2_def, +#endif +#ifdef CONFIG_SCHED_ARINC653 &sched_arinc653_def, +#endif +#ifdef CONFIG_SCHED_RTDS &sched_rtds_def, +#endif }; static struct scheduler __read_mostly ops; diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index fc61fc3..246338e 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -850,8 +850,13 @@ static inline bool_t is_vcpu_online(const struct vcpu *v) return !test_bit(_VPF_down, &v->pause_flags); } +#ifdef CONFIG_SCHED_CREDIT void set_vcpu_migration_delay(unsigned int delay); unsigned int get_vcpu_migration_delay(void); +#else +static inline void set_vcpu_migration_delay(unsigned int delay) { } +static inline unsigned int get_vcpu_migration_delay(void) { return 0; } +#endif extern bool_t sched_smt_power_savings;