[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/3] xen/sched: populate cpupool0 only after all cpus are up
On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote: > With core or socket scheduling we need to know the number of siblings > per scheduling unit before we can setup the scheduler properly. In > order to prepare that do cpupool0 population only after all cpus are > up. > > With that in place there is no need to create cpupool0 earlier, so > do that just before assigning the cpus. Initialize free cpus with all > online cpus at that time in order to be able to add the cpu notifier > late, too. > So, now that this series has been made independent, I think that mentions to the core-scheduling one should be dropped. I mean, it is at least possible that this series would go in, while the core-scheduling one never will. And at that point, it would be very hard, for someone doing archaeology, to understand what went on. It seems to me that, this patch, simplifies cpupool initialization (as, e.g., the direct call to the CPU_ONLINE notifier for the BSP was IMO rather convoluted). And that is made possible by moving the initialization itself to a later point, making all the online CPUs look like free CPUs, and using the standard (internal) API directly (i.e., cpupool_assign_cpu_locked()) to add them to Pool-0. So, I'd kill the very first sentence and rearrange the rest to include at least a quick mention to the simplification that we achieve. Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere) Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |