Linux mandates that the boot CPU cannot be isolated - so it must ALWAYS be included in the ODP 'control' cpumask. However on hardware installations with a large core count more non-isolated control CPUs will probably be needed in order to offload kernel housekeeping work from the isolated 'worker' CPUs.
odp_cpumask_default_control() should always return a cpumask including all CPUs available for control threads - so we probably shouldn't constrain it to return only a singie cpu. Additionally it might be called from any thread in order to obtain a cpumask to use for spawning new control threads - so we probably don't want to pin the calling thread unconditionally to a single CPU during execution of odp_cpumask_default_control(). Now that I am aware of the problems created by allowing the primary control thread to migrate among multiple CPUs I will investigate means of addressing this inside the isolation setup helpers. These helpers will have to be called prior to calling odp_init_global() because they have to set up the new cpumasks prior to calling that function. What I have in mind is pinning the primary control thread to a single CPU randomly selected from the available control cpumask during isolation setup. This would avoid scalability issues with forcing the primary control threads unconditionally onto CPU 0. However, there are some wrinkles with setting CPU affinity and with explicitly migrating tasks across scheduler domains, so I will need to do some experimenting there to arrive at a workable solution which pins the primary control thread to a single CPU but doesn't kill its ability to spawn new threads or processes anywhere in the available control or worker cpu sets. In the end I think we should be able to satisfy these issues with little or no change to linux-generic. Possibly I will need to add logic to pin this thread to CPU 0 in odp_init_global() if no isolation setup was specified on the command line of the ODP application / instance. Gary _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
