From: imran.f.khan@oracle.com
To: Thomas Gleixner <tglx@linutronix.de>
Cc: john.stultz@linaro.org, sboyd@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Query about timer wheel API
Date: Thu, 16 Jan 2025 00:48:56 +1100 [thread overview]
Message-ID: <266befac-b781-4a37-9261-6d956cceb36f@oracle.com> (raw)
In-Reply-To: <874j20cqp0.ffs@tglx>
Hello Thomas,
Thank you so much for your feedback.
On 15/1/2025 9:32 pm, Thomas Gleixner wrote:
> On Mon, Dec 23 2024 at 11:14, imran f. khan wrote:
>> Could you kindly help me, regarding a query about timer wheel APIs.
>> Right now we use add_timer or add_timer_on, to add a timer to any
>> or to a specific CPU respectively.
>> Would it be useful to have an interface like try_add_timer_on, that
>> would return an error or would use add_timer, if the specified CPU is
>> offline.
>>
>> Recently we have come across some bugs in the RDS code, where a delayed
>> work was being queued on an offlined CPU and as a result of that the
>> underlying timer was not firing, which in turn meant that the work was
>> never able to make it to the intended worker_pool.
>
> Urgh. Clearly add_timer_on() lacks a check and a warning for that.
>
>> I understand that this is something that needs fixing at caller side and
>> we are taking that approach.
>>
>> But I also wanted to understand if there is some scope of change on timer
>> side, for such situations. I saw your reply in [1] and agree with your point.
>> But that conversation is more than a decade old, so I thought of asking this
>> question, assuming that there may be some other use cases that can utilize
>> this new interface.
>>
>> One can also ask to change queue_delayed_work_on or have an equivalent,
>> that would check if CPU is online before doing add_timer_on but I am not sure
>> if workqueue is the only subsystem that can run into this situation.
>
> I have no idea.
>
> That said, I'm not opposed to have a function like
> timer_try_add_on_cpu(), which validates that the CPU is online and
> returns true if the timer is queued or false if the target CPU is
> offline. Then the call site can decided what to do with that
> situation. That's way better than queueing it on some randomly picked
> online CPU silently.
>
I have sent a couple of patches at [1] in this regard. Could you kindly
have a look and let me know your feedback.
Thanks,
Imran
[1]: https://lore.kernel.org/all/20250115134111.2703089-1-imran.f.khan@oracle.com/
prev parent reply other threads:[~2025-01-15 13:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-23 0:14 Query about timer wheel API imran.f.khan
2024-12-23 12:51 ` Hillf Danton
2024-12-23 14:20 ` imran.f.khan
2024-12-24 10:41 ` Hillf Danton
2024-12-24 12:41 ` imran.f.khan
2024-12-25 11:01 ` Hillf Danton
2024-12-26 13:07 ` imran.f.khan
2024-12-27 10:30 ` Hillf Danton
2025-01-15 10:32 ` Thomas Gleixner
2025-01-15 13:48 ` imran.f.khan [this message]
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=266befac-b781-4a37-9261-6d956cceb36f@oracle.com \
--to=imran.f.khan@oracle.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sboyd@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.