On 04/08/2015 09:28 AM, Frederic Weisbecker wrote:
On Mon, Apr 06, 2015 at 03:45:55PM -0400, cmetcalf@xxxxxxxxxx wrote:From: Chris Metcalf <cmetcalf@xxxxxxxxxx> This change allows some cores to be excluded from running the smp_hotplug_thread tasks. The motivating example for this is the watchdog threads, which by default we don't want to run on any enabled nohz_full cores. Signed-off-by: Chris Metcalf <cmetcalf@xxxxxxxxxx> --- include/linux/smpboot.h | 2 ++ kernel/smpboot.c | 11 ++++++++--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h index d600afb21926..de2f64a98108 100644 --- a/include/linux/smpboot.h +++ b/include/linux/smpboot.h @@ -27,6 +27,7 @@ struct smpboot_thread_data; * @pre_unpark: Optional unpark function, called before the thread is * unparked (cpu online). This is not guaranteed to be * called on the target cpu of the thread. Careful! + * @exclude_mask: Optional cpumask, specifying cores to exclude. * @selfparking: Thread is not parked by the park function. * @thread_comm: The base name of the thread */ @@ -41,6 +42,7 @@ struct smp_hotplug_thread { void (*park)(unsigned int cpu); void (*unpark)(unsigned int cpu); void (*pre_unpark)(unsigned int cpu); + cpumask_t *exclude_mask;The usual pattern for cpumasks is to use them as affinity values instead of non-affinity values.
Yes. The issue here is that as cpus come and go from the hotplug set, the ones that we want to exclude remain fixed. If we do it the way you propose (and it's the way I originally did it), it means that if a new cpu comes online you automatically treat it as nohz_full, which seems wrong to me. I suppose we could add another callback so that the smp_hotplug_thread struct could explicitly decide how to mark any new cpu that comes online, but that all seems more complicated than my final suggestion. What do you think? -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
