Re: [PATCH v5 1/2] smpboot: allow excluding cpus from the smpboot threads

Chris Metcalf
2015-04-08T14:07:04Z

On 04/08/2015 09:28 AM, Frederic Weisbecker wrote:
> On Mon, Apr 06, 2015 at 03:45:55PM -0400, cmetcalf@ezchip.com wrote:
>> From: Chris Metcalf <cmetcalf@ezchip.com>
>>
>> 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@ezchip.com>
>> ---
>> 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