From: imran.f.khan@oracle.com
To: Hillf Danton <hdanton@sina.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: Tue, 24 Dec 2024 01:20:48 +1100 [thread overview]
Message-ID: <801e569c-4f86-4bb5-a255-b861b86cb773@oracle.com> (raw)
In-Reply-To: <20241223125202.407-1-hdanton@sina.com>
Hello Hillf,
On 23/12/2024 11:51 pm, Hillf Danton wrote:
> On Mon, 23 Dec 2024 11:14:21 +1100 imran.f.khan@oracle.com
>>
>> 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
>
> Such a queue could not happen given irq disabled in queue_delayed_work_on().
> Did you see it upstream?
>
You mean upstream RDS or upstream workqueue ? For RDS I need to check, but with
upstream v6.6 kernel, I was able to submit a delayed work to an offlined CPU.
The delayed work would never happen and I can see corresponding timer in timer
list of offlined CPU (using crash).
Once the CPU is brought back online, depending on the workload the work handler
gets executed.
I used following test module:
===============
#include <linux/module.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/workqueue.h>
#include <linux/completion.h>
#include <linux/delay.h>
#include <linux/slab.h>
#include <linux/jiffies.h>
#define TIMEOUT 1 /* test timeout in secs */
#define NUM_WORK_ITEMS 1 /* number of work items to submit */
static DEFINE_MUTEX(mutex);
static DEFINE_MUTEX(dwork_func_mutex);
static void delayed_work_func(struct work_struct *data)
{
int cpu;
mutex_lock(&dwork_func_mutex);
cpu = get_cpu();
pr_err("%s invoked for work: 0x%px on cpu#%d \n", __func__, data, cpu);
put_cpu();
mutex_unlock(&dwork_func_mutex);
}
static int param_set_queue_work_on_cpu(const char *val, const struct kernel_param *kp)
{
int cpu, this_cpu, i;
struct delayed_work *dwork = NULL;
if (!mutex_trylock(&mutex))
return -EBUSY;
cpu = simple_strtoul(val, NULL, 0);
/*if (!cpu_present(cpu))
return -EINVAL;*/
for (i = 0; i < NUM_WORK_ITEMS; i++) {
dwork = kzalloc(sizeof(struct delayed_work), GFP_KERNEL);
if(dwork) {
this_cpu = get_cpu();
INIT_DELAYED_WORK(dwork, delayed_work_func);
queue_delayed_work_on(cpu, system_wq, dwork, msecs_to_jiffies(10000));
pr_err("Submitted dwork 0x%px on %s cpu#%d \n", dwork, cpu_online(cpu)?"online":"offline", cpu);
put_cpu();
}
}
mutex_unlock(&mutex);
return 0;
}
module_param_call(queue_work_on_cpu, param_set_queue_work_on_cpu, NULL, NULL, 0600);
static int __init workqueue_study_init(void)
{
pr_err("module_init \n");
return 0;
}
static void workqueue_study_exit(void)
{
pr_err("module_exit \n");
}
MODULE_AUTHOR("Imran Khan <imran.eie.85@gmail.com>");
MODULE_DESCRIPTION("Workqueue study");
MODULE_LICENSE("GPL");
module_init(workqueue_study_init);
module_exit(workqueue_study_exit);
===========
This module gives an interface at:
/sys/module/<module name>/params/queue_work_on_cpu
Writing X there would submit a delayed_work (delay 10 secs)
to CPU X.
We can see if CPU X is online, submitted work gets executed
after around 10 secs. But if CPU X is offline, the submitted
work handler does not get fired unless the CPU has been brought
back online.
Thanks,
Imran
>> underlying timer was not firing, which in turn meant that the work was
>> never able to make it to the intended worker_pool.
next prev parent reply other threads:[~2024-12-23 14:21 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 [this message]
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
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=801e569c-4f86-4bb5-a255-b861b86cb773@oracle.com \
--to=imran.f.khan@oracle.com \
--cc=hdanton@sina.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 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.