[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5527ECC1.4090903@ezchip.com>
Date: Fri, 10 Apr 2015 11:31:13 -0400
From: Chris Metcalf <cmetcalf@...hip.com>
To: Frederic Weisbecker <fweisbec@...il.com>
CC: "Peter Zijlstra (Intel)" <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Ingo Molnar <mingo@...hat.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 1/2] nohz: add tick_nohz_full_add_cpus_to() and _remove_cpus_from()
APIs
On 04/09/2015 09:34 PM, Frederic Weisbecker wrote:
> On Thu, Apr 09, 2015 at 02:01:45PM -0400, Chris Metcalf wrote:
>> --- a/include/linux/tick.h
>> +++ b/include/linux/tick.h
>> @@ -186,6 +186,18 @@ static inline bool tick_nohz_full_cpu(int cpu)
>> return cpumask_test_cpu(cpu, tick_nohz_full_mask);
>> }
>>
>> +static inline void tick_nohz_full_add_cpus_to(struct cpumask *mask)
> Or tick_nohz_full_affine() ?
I'd vote no to that, I think - the first problem I see is that it doesn't
make very clear that it modifies the argument, which is the problem
Peter Z has been having from the beginning with some suggestions.
The second problem is that it sounds like it might be setting the
argument unconditionally to the nohz_full set, when in fact it's doing
a cpumask_or() to increase the set of cpus further.
> + /* nohz_full won't take effect without isolating the cpus. */
> + tick_nohz_full_remove_cpus_from(cpu_isolated_map);
> This should be the other one I guess.
>
<Slaps self on forehead> Thanks!
Now off to do some actual testing before sending the next patchset :-)
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists