On 28/05/2019 13:47, Jan Beulich wrote: >>>> On 28.05.19 at 12:33, <jgr...@suse.com> wrote: >> Instead of having a full blown scheduler running for the free cpus >> add a very minimalistic scheduler for that purpose only ever scheduling >> the related idle vcpu. This has the big advantage of not needing any >> per-cpu, per-domain or per-scheduling unit data for free cpus and in >> turn simplifying moving cpus to and from cpupools a lot. > > And the null scheduler is not minimalistic enough?
The main disadvantage of the null scheduler are the need for private data (which has to be allocated/freed on scheduler switch), its not yet perfect stability, and its "complexity" (e.g. 900 lines vs. 50). > >> --- a/xen/arch/arm/smpboot.c >> +++ b/xen/arch/arm/smpboot.c >> @@ -350,8 +350,6 @@ void start_secondary(unsigned long boot_phys_offset, >> >> setup_cpu_sibling_map(cpuid); >> >> - scheduler_percpu_init(cpuid); >> - >> /* Run local notifiers */ >> notify_cpu_starting(cpuid); >> /* >> --- a/xen/arch/x86/smpboot.c >> +++ b/xen/arch/x86/smpboot.c >> @@ -382,8 +382,6 @@ void start_secondary(void *unused) >> >> set_cpu_sibling_map(cpu); >> >> - scheduler_percpu_init(cpu); >> - >> init_percpu_time(); >> >> setup_secondary_APIC_clock(); > > Seeing you revert here what an earlier patch in the series has added, > I don't suppose re-ordering could avoid this code churn? This would require another major shuffling of patches. I'd like to avoid that. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
