From: Waiman Long <llong@redhat.com>
To: Gabriele Monaco <gmonaco@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Frederic Weisbecker <frederic@kernel.org>
Subject: Re: [PATCH] timers: Exclude isolated cpus from timer migation
Date: Thu, 10 Apr 2025 10:21:05 -0400 [thread overview]
Message-ID: <b122fbf7-14b9-49a0-a727-97adcca9924b@redhat.com> (raw)
In-Reply-To: <2c9d71fd79d7d1cec66e48bcb87b39a874858f01.camel@redhat.com>
On 4/10/25 6:38 AM, Gabriele Monaco wrote:
> On Thu, 2025-04-10 at 10:26 +0200, Thomas Gleixner wrote:
>> On Thu, Apr 10 2025 at 08:54, Gabriele Monaco wrote:
>>>
>>> +/* cpumask excluded from migration */
>>> +static cpumask_var_t tmigr_unavailable_cpumask;
>> Why is this a negated mask instead of being the obvious and intuitive
>> available mask?
> Well, the way I started writing the patch I found it easier to do the
> double andnot in tmigr_isolated_exclude_cpumask to see what changed.
> I see the way it evolved is just messier..
> I'll apply your solution which seems much neater!
>
>>> if (firstexp != KTIME_MAX) {
>>> - migrator = cpumask_any_but(cpu_online_mask, cpu);
>>> + migrator = cpumask_nth_andnot(0, cpu_possible_mask,
>>> + tmigr_unavailable_cpumask);
>> That's exactly what this negated mask causes: incomprehensible code.
>>
>> cpumask_clear_cpu(cpu, available_mask);
>> ...
>> migrator = cpumask_first(available_mask);
>>
>> is too simple and obvious, right?
>>
>>> + /* Fall back to any online in case all are isolated. */
>> How can that happen? There is always at least _ONE_ housekeeping,
>> non-isolated, CPU online, no?
>>
> In my understanding it shouldn't, but I'm not sure there's anything
> preventing the user from isolating everything via cpuset.
> Anyway that's something no one in their mind should do, so I guess I'd
> just opt for the cpumask_first (or actually cpumask_any, like before
> the change).
No, cpuset is not allowed to take all the CPUs from the cgroup root
(housekeeping CPUs). So it can't happen.
>>> + if (migrator >= nr_cpu_ids)
>>> + migrator = cpumask_any_but(cpu_online_mask, cpu);
>>> work_on_cpu(migrator, tmigr_trigger_active, NULL);
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> -static int tmigr_cpu_online(unsigned int cpu)
>>> +static int tmigr_cpu_available(unsigned int cpu)
>>> {
>>> - struct tmigr_cpu *tmc = this_cpu_ptr(&tmigr_cpu);
>>> + struct tmigr_cpu *tmc = per_cpu_ptr(&tmigr_cpu, cpu);
>>>
>>> /* Check whether CPU data was successfully initialized */
>>> if (WARN_ON_ONCE(!tmc->tmgroup))
>>> return -EINVAL;
>>>
>>> + /* Silently ignore online requests if isolated */
>> This comment makes no sense.
>>
>> /* Isolated CPUs are not participating in timer migration */
>>
>> makes it entirely clear what this is about, no?
>>
>> That brings me to the general design decision here. Your changelog
>> explains at great length WHAT the change is doing, but completely
>> fails
>> to explain the consequences and the rationale why this is the right
>> thing to do.
>>
>> By excluding the isolated CPUs from migration completely, any
>> 'global'
>> timer, which is armed on such a CPU, has to be expired on that
>> isolated
>> CPU. That's fundamentaly different from e.g. RCU isolation.
>>
>> It might be the right thing to do and harmless, but without a proper
>> explanation it's a silent side effect of your changes, which leaves
>> people scratching their heads.
> Mmh, essentially the idea is that global timer should not migrate from
> housekeeping to isolated cores. I assumed the opposite never occurs (as
> global timers /should/ not even start on isolated cores on a properly
> isolated system), but you're right, that's not quite true.
>
> Thinking about it now, since global timers /can/ start on isolated
> cores, that makes them quite different from offline ones and probably
> considering them the same is just not the right thing to do..
>
> I'm going to have a deeper thought about this whole approach, perhaps
> something simpler just preventing migration in that one direction would
> suffice.
>
>>> + if (cpu_is_isolated(cpu))
>>> + return 0;
>>> raw_spin_lock_irq(&tmc->lock);
>>> - trace_tmigr_cpu_online(tmc);
>>> + trace_tmigr_cpu_available(tmc);
>>> tmc->idle = timer_base_is_idle();
>>> if (!tmc->idle)
>>> __tmigr_cpu_activate(tmc);
>>> - tmc->online = true;
>>> + tmc->available = true;
>>> + tmc->idle = true;
>> How so?
>>
>>> + cpumask_clear_cpu(cpu, tmigr_unavailable_cpumask);
>>> raw_spin_unlock_irq(&tmc->lock);
>>> return 0;
>>> }
>>>
>>> +int tmigr_isolated_exclude_cpumask(cpumask_var_t exclude_cpumask)
>> cpumask_var_t is wrong here. 'const struct cpumask *' is what you
>> want.
> You mean in the function argument? That's exactly how it is handled in
> workqueue_unbound_exclude_cpumask. I get cpumask_var_t is not
> necessarily a pointer, perhaps it's worth changing it there too..
> Or am I missing your point?
cpumask_var_t can be interchangeable with "struct cpumask *" as long as
the passed-in cpumask is not being modified.
Cheers,
Longman
next prev parent reply other threads:[~2025-04-10 14:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 6:54 Gabriele Monaco
2025-04-10 8:26 ` Thomas Gleixner
2025-04-10 10:38 ` Gabriele Monaco
2025-04-10 13:03 ` Frederic Weisbecker
2025-04-10 13:15 ` Thomas Gleixner
2025-04-10 13:27 ` Frederic Weisbecker
2025-04-10 13:56 ` Gabriele Monaco
2025-04-10 14:20 ` Frederic Weisbecker
2025-04-10 14:46 ` Thomas Gleixner
2025-04-10 14:54 ` Frederic Weisbecker
2025-04-10 15:06 ` Waiman Long
2025-04-10 14:46 ` Gabriele Monaco
2025-04-10 14:59 ` Frederic Weisbecker
2025-04-10 15:05 ` Gabriele Monaco
2025-04-10 15:32 ` Frederic Weisbecker
2025-04-11 7:08 ` Gabriele Monaco
2025-04-11 11:31 ` Frederic Weisbecker
2025-04-11 13:02 ` Gabriele Monaco
2025-04-11 22:57 ` Frederic Weisbecker
2025-04-14 8:06 ` Gabriele Monaco
2025-04-10 14:35 ` Waiman Long
2025-04-10 14:43 ` Frederic Weisbecker
2025-04-10 14:49 ` Gabriele Monaco
2025-04-10 14:50 ` Waiman Long
2025-04-10 14:56 ` Frederic Weisbecker
2025-04-10 13:08 ` Thomas Gleixner
2025-04-10 14:21 ` Waiman Long [this message]
2025-04-10 14:32 ` Waiman Long
2025-04-11 7:12 ` kernel test robot
2025-04-11 9:27 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b122fbf7-14b9-49a0-a727-97adcca9924b@redhat.com \
--to=llong@redhat.com \
--cc=frederic@kernel.org \
--cc=gmonaco@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®