The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Hillf Danton <hdanton@sina.com>
To: imran.f.khan@oracle.com
Cc: Thomas Gleixner <tglx@linutronix.de>, Tejun Heo <tj@kernel.org>,
	john.stultz@linaro.org, sboyd@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Query about timer wheel API
Date: Wed, 25 Dec 2024 19:01:45 +0800	[thread overview]
Message-ID: <20241225110146.482-1-hdanton@sina.com> (raw)
In-Reply-To: <910a73af-a221-4e5b-ad5b-a2a1bdb8c8c3@oracle.com>

On Tue, 24 Dec 2024 23:41:48 +1100 imran.f.khan@oracle.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?

  reply	other threads:[~2024-12-25 11:07 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 [this message]
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

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=20241225110146.482-1-hdanton@sina.com \
    --to=hdanton@sina.com \
    --cc=imran.f.khan@oracle.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    /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