Re: [PATCH 3/5] tick/broadcast: Prefer per-cpu oneshot wakeup timers to broadcast

[Will Deacon]

On Fri, May 21, 2021 at 03:49:39PM +0200, Thomas Gleixner wrote:
> On Fri, May 21 2021 at 12:25, Will Deacon wrote:
> > On Fri, May 21, 2021 at 05:25:41AM +0300, Mika Penttilä wrote:
> >> On 20.5.2021 21.47, Will Deacon wrote:
> >> >   /*
> >> >    * Conditionally install/replace broadcast device
> >> >    */
> >> > -void tick_install_broadcast_device(struct clock_event_device *dev)
> >> > +void tick_install_broadcast_device(struct clock_event_device *dev, int cpu)
> >> >   {
> >> >   	struct clock_event_device *cur = tick_broadcast_device.evtdev;
> >> > +	if (tick_set_oneshot_wakeup_device(dev, cpu))
> >> > +		return;
> >> > +
> >> >   	if (!tick_check_broadcast_device(cur, dev))
> >> >   		return;
> >> 
> >> Does this disable hpet registering as a global broadcast device on x86 ? I
> >> think it starts with cpumask = cpu0 so it qualifies for a percpu wakeup
> >> timer.
> >
> > Well spotted, I think you're probably right. I'll try to reproduce on my
> > laptop to confirm, but I hadn't noticed the tricks played with the cpumask
> > on x86.
> >
> > I'll probably need to rework things so that we install the broadcast timer
> > first, but prefer global devices.
> 
> HPET has cpumask(0) but does not have CLOCK_EVT_FEAT_PERCPU set. The
> feature flag is a clear indicator for per cpu.

Thanks, that makes the logic much neater because that feature already causes
the device to be rejected as the broadcast so there's no need to worry about
considering a device for both broadcast and a local wakeup.

I'll post a v2 on Monday once I've tested it on my laptop (which is throwing
ext4 errors at the moment...)

Will