mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gabriele Monaco <gmonaco@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	 Frederic Weisbecker <frederic@kernel.org>,
	Waiman Long <longman@redhat.com>
Subject: Re: [PATCH] timers: Exclude isolated cpus from timer migation
Date: Thu, 10 Apr 2025 12:38:25 +0200	[thread overview]
Message-ID: <2c9d71fd79d7d1cec66e48bcb87b39a874858f01.camel@redhat.com> (raw)
In-Reply-To: <87ecy0tob1.ffs@tglx>

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).

> > + 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?

> 
> > +{
> > + int cpu;
> > + cpumask_var_t cpumask;
> 
> https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#coding-style-notes
> 
> > + if (!zalloc_cpumask_var(&cpumask, GFP_KERNEL))
> > + return -ENOMEM;
> > +
> > + cpumask_copy(cpumask, tmigr_unavailable_cpumask);
> 
> What serializes this against concurrent CPU hotplug? I assume it's
> done
> by the caller, but then this code should have a lockdep assert to
> validate it. If it's not, then this is broken.
> 
> As it is serialized it does not need a copy either, right?
> 
> > + /* Was not excluded but should be excluded now. */
> > + for_each_cpu_andnot(cpu, exclude_cpumask, cpumask)
> > + tmigr_cpu_unavailable(cpu);
> > +
> > + /* Was excluded but should be included now */
> > + for_each_cpu_andnot(cpu, cpumask, exclude_cpumask)
> > + if (cpu_online(cpu))
> > + tmigr_cpu_available(cpu);
> 
> My brain hurts by now.
> 
>          for_each_cpu_and(cpu, available_mask, exclude_mask)
>           tmigr_cpu_unavailable(cpu);
> 
>          for_each_cpu_andnot(cpu, cpu_online_mask, exclude_mask) {
>           if (!cpumask_test_cpu(cpu, available_mask))
>                  tmigr_cpu_available(cpu);
>          }
> 
> No?
> 
> Also this patch is doing too many things at once. It want's to be
> split
> into:
> 
>     Patch 1: Rename 'online' to 'available' (bit and function names)
>     Patch 2: Add the available mask logic
>     Patch 3: Add the isolation functionality
> 

Good point, I'll keep it in mind if the patch keeps this shape.

Thanks for the feedback,
Gabriele


  reply	other threads:[~2025-04-10 10:38 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 [this message]
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
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=2c9d71fd79d7d1cec66e48bcb87b39a874858f01.camel@redhat.com \
    --to=gmonaco@redhat.com \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --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®