[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241225110146.482-1-hdanton@sina.com>
Date: Wed, 25 Dec 2024 19:01:45 +0800
From: Hillf Danton <hdanton@...a.com>
To: imran.f.khan@...cle.com
Cc: Thomas Gleixner <tglx@...utronix.de>,
Tejun Heo <tj@...nel.org>,
john.stultz@...aro.org,
sboyd@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: Query about timer wheel API
On Tue, 24 Dec 2024 23:41:48 +1100 imran.f.khan@...cle.com
>
> the query was not about why its (not) working with my module. The test module, in its
> current form, is just to show that a timer-wheel timer could be inserted in timer list
> of an offlined CPU.
Your module helps understand your query.
>
> What you have suggested, we are already doing it in RDS code (mentioned in my earlier messages).
> Also just using cpu_online may not be enough, unless we do it under get/put_online_cpus.
>
Same pattern is in smp_call_function_single() where ckecking cpu after get_cpu().
But different one in smp_call_on_cpu().
> If you see, my query was more towards, what should "add_timer_on" do for such cases or
> can we have another function like try_add_timer_on that tries to put the timer on specific
> CPU, but puts it else where if that CPU is offline. Is it worth having such an interface
> or should we stick to the current approach of fixing this on the caller side.
The number of reports that timer is queued on offline cpu in 2024 alone raises
the (known) question -- what sense could be made by adding check of cpu in the
pathes like queuing work and arming timer?
Powered by blists - more mailing lists