| Message ID | 20250210153253.460471-3-gmonaco@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v6,1/3] sched: Compact RSEQ concurrency IDs with reduced threads and affinity | expand |
Hello,
kernel test robot noticed "WARNING:at_kernel/workqueue.c:#__queue_delayed_work" on:
commit: 287adf9e9c1fa8a0e2b50ab1a1de3e4572a8ccd2 ("[PATCH v6 2/3] sched: Move task_mm_cid_work to mm delayed work")
url: https://github.com/intel-lab-lkp/linux/commits/Gabriele-Monaco/sched-Compact-RSEQ-concurrency-IDs-with-reduced-threads-and-affinity/20250210-233547
patch link: https://lore.kernel.org/all/20250210153253.460471-3-gmonaco@redhat.com/
patch subject: [PATCH v6 2/3] sched: Move task_mm_cid_work to mm delayed work
in testcase: boot
config: x86_64-randconfig-004-20250211
compiler: clang-19
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202502131405.1ba0803f-lkp@intel.com
[ 2.640924][ T0] ------------[ cut here ]------------
[ 2.641646][ T0] WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:2495 __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9))
[ 2.642874][ T0] Modules linked in:
[ 2.643381][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.14.0-rc2-00002-g287adf9e9c1f #1
[ 2.644582][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 2.645943][ T0] RIP: 0010:__queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9))
[ 2.646755][ T0] Code: 44 89 fe 4c 89 33 e8 6d 24 19 00 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 c9 31 ff 31 d2 31 f6 c3 e8 7f 87 25 00 90 <0f> 0b 90 e9 58 fd ff ff e8 71 87 25 00 90 0f 0b 90 e9 80 fd ff ff
All code
========
0: 44 89 fe mov %r15d,%esi
3: 4c 89 33 mov %r14,(%rbx)
6: e8 6d 24 19 00 call 0x192478
b: 48 83 c4 08 add $0x8,%rsp
f: 5b pop %rbx
10: 41 5c pop %r12
12: 41 5d pop %r13
14: 41 5e pop %r14
16: 41 5f pop %r15
18: 5d pop %rbp
19: 31 c0 xor %eax,%eax
1b: 31 c9 xor %ecx,%ecx
1d: 31 ff xor %edi,%edi
1f: 31 d2 xor %edx,%edx
21: 31 f6 xor %esi,%esi
23: c3 ret
24: e8 7f 87 25 00 call 0x2587a8
29: 90 nop
2a:* 0f 0b ud2 <-- trapping instruction
2c: 90 nop
2d: e9 58 fd ff ff jmp 0xfffffffffffffd8a
32: e8 71 87 25 00 call 0x2587a8
37: 90 nop
38: 0f 0b ud2
3a: 90 nop
3b: e9 80 fd ff ff jmp 0xfffffffffffffdc0
Code starting with the faulting instruction
===========================================
0: 0f 0b ud2
2: 90 nop
3: e9 58 fd ff ff jmp 0xfffffffffffffd60
8: e8 71 87 25 00 call 0x25877e
d: 90 nop
e: 0f 0b ud2
10: 90 nop
11: e9 80 fd ff ff jmp 0xfffffffffffffd96
[ 2.649301][ T0] RSP: 0000:ffffffffab007d80 EFLAGS: 00010046
[ 2.650081][ T0] RAX: 0000000000000000 RBX: ffff888100090b98 RCX: 0000000000000000
[ 2.651084][ T0] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 2.652078][ T0] RBP: ffffffffab007db0 R08: 0000000000000000 R09: 0000000000000000
[ 2.653077][ T0] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 2.654101][ T0] R13: 0000000000000040 R14: 0000000000000019 R15: 0000000000000040
[ 2.655112][ T0] FS: 0000000000000000(0000) GS:ffff8883af200000(0000) knlGS:0000000000000000
[ 2.656263][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.657103][ T0] CR2: ffff88843ffff000 CR3: 00000001d3617000 CR4: 00000000000000b0
[ 2.658128][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2.659147][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2.660143][ T0] Call Trace:
[ 2.660553][ T0] <TASK>
[ 2.660934][ T0] ? show_regs (arch/x86/kernel/dumpstack.c:479)
[ 2.661524][ T0] ? __warn (kernel/panic.c:748)
[ 2.662065][ T0] ? __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9))
[ 2.662796][ T0] ? __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9))
[ 2.663535][ T0] ? report_bug (lib/bug.c:?)
[ 2.664119][ T0] ? __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9))
[ 2.664836][ T0] ? handle_bug (arch/x86/kernel/traps.c:285)
[ 2.665404][ T0] ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))
[ 2.665848][ T0] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)
[ 2.666292][ T0] ? __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9))
[ 2.666762][ T0] queue_delayed_work_on (kernel/workqueue.c:?)
[ 2.667215][ T0] mm_init (include/linux/workqueue.h:? include/linux/workqueue.h:817 include/linux/mm_types.h:1261 kernel/fork.c:1310)
[ 2.667575][ T0] mm_alloc (kernel/fork.c:?)
[ 2.667916][ T0] ? x86_64_start_reservations (usercopy_64.c:?)
[ 2.668400][ T0] poking_init (arch/x86/mm/init.c:822)
[ 2.668777][ T0] ? x86_64_start_reservations (usercopy_64.c:?)
[ 2.669266][ T0] start_kernel (init/main.c:959)
[ 2.669671][ T0] x86_64_start_reservations (usercopy_64.c:?)
[ 2.670140][ T0] x86_64_start_kernel (arch/x86/kernel/head64.c:445 (discriminator 2))
[ 2.670574][ T0] common_startup_64 (arch/x86/kernel/head_64.S:421)
[ 2.671018][ T0] </TASK>
[ 2.671271][ T0] irq event stamp: 0
[ 2.671595][ T0] hardirqs last enabled at (0): 0x0
[ 2.672192][ T0] hardirqs last disabled at (0): 0x0
[ 2.672789][ T0] softirqs last enabled at (0): 0x0
[ 2.673386][ T0] softirqs last disabled at (0): 0x0
[ 2.674005][ T0] ---[ end trace 0000000000000000 ]---
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20250213/202502131405.1ba0803f-lkp@intel.com
On Thu, 2025-02-13 at 14:52 +0800, kernel test robot wrote: > kernel test robot noticed > "WARNING:at_kernel/workqueue.c:#__queue_delayed_work" on: > > [ 2.640924][ T0] ------------[ cut here ]------------ > [ 2.641646][ T0] WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:2495 > __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9)) > [ 2.642874][ T0] Modules linked in: > [ 2.643381][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted > 6.14.0-rc2-00002-g287adf9e9c1f #1 > [ 2.644582][ T0] Hardware name: QEMU Standard PC (i440FX + > PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 > [ 2.645943][ T0] RIP: 0010:__queue_delayed_work > (kernel/workqueue.c:2495 (discriminator 9)) There seem to be major problems with this configuration, I'm trying to understand what's wrong but, for the time being, this patchset is not ready for inclusion. Gabriele
On 2025-02-13 08:25, Gabriele Monaco wrote: > On Thu, 2025-02-13 at 14:52 +0800, kernel test robot wrote: >> kernel test robot noticed >> "WARNING:at_kernel/workqueue.c:#__queue_delayed_work" on: >> >> [ 2.640924][ T0] ------------[ cut here ]------------ >> [ 2.641646][ T0] WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:2495 >> __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9)) >> [ 2.642874][ T0] Modules linked in: >> [ 2.643381][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted >> 6.14.0-rc2-00002-g287adf9e9c1f #1 >> [ 2.644582][ T0] Hardware name: QEMU Standard PC (i440FX + >> PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 >> [ 2.645943][ T0] RIP: 0010:__queue_delayed_work >> (kernel/workqueue.c:2495 (discriminator 9)) > > There seem to be major problems with this configuration, I'm trying to > understand what's wrong but, for the time being, this patchset is not > ready for inclusion. I think there is an issue with the order of init functions at boot. poking_init() calls mm_alloc(), which ends up calling mm_init(). The WARN_ON() is about a NULL wq pointer, which I suspect happens if poking_init() is called before workqueue_init_early(), which allocates system_wq. Indeed, in start_kernel(), poking_init() is called before workqueue_init_early(). I'm not sure what are the init order dependencies across subsystems here. There is the following order in start_kernel(): [...] mm_core_init(); poking_init(); ftrace_init(); /* trace_printk can be enabled here */ early_trace_init(); /* * Set up the scheduler prior starting any interrupts (such as the * timer interrupt). Full topology setup happens at smp_init() * time - but meanwhile we still have a functioning scheduler. */ sched_init(); if (WARN(!irqs_disabled(), "Interrupts were enabled *very* early, fixing it\n")) local_irq_disable(); radix_tree_init(); maple_tree_init(); /* * Set up housekeeping before setting up workqueues to allow the unbound * workqueue to take non-housekeeping into account. */ housekeeping_init(); /* * Allow workqueue creation and work item queueing/cancelling * early. Work item execution depends on kthreads and starts after * workqueue_init(). */ workqueue_init_early(); [...] So either we find a way to reorder this, or we make sure poking_init() does not require the workqueue. Thanks, Mathieu
On Thu, 2025-02-13 at 08:55 -0500, Mathieu Desnoyers wrote: > On 2025-02-13 08:25, Gabriele Monaco wrote: > > On Thu, 2025-02-13 at 14:52 +0800, kernel test robot wrote: > > > kernel test robot noticed > > > "WARNING:at_kernel/workqueue.c:#__queue_delayed_work" on: > > > > > > [ 2.640924][ T0] ------------[ cut here ]------------ > > > [ 2.641646][ T0] WARNING: CPU: 0 PID: 0 at > > > kernel/workqueue.c:2495 > > > __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9)) > > > [ 2.642874][ T0] Modules linked in: > > > [ 2.643381][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not > > > tainted > > > 6.14.0-rc2-00002-g287adf9e9c1f #1 > > > [ 2.644582][ T0] Hardware name: QEMU Standard PC (i440FX + > > > PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 > > > [ 2.645943][ T0] RIP: 0010:__queue_delayed_work > > > (kernel/workqueue.c:2495 (discriminator 9)) > > > > There seem to be major problems with this configuration, I'm trying > > to > > understand what's wrong but, for the time being, this patchset is > > not > > ready for inclusion. > > I think there is an issue with the order of init functions at boot. > > poking_init() calls mm_alloc(), which ends up calling mm_init(). > > The WARN_ON() is about a NULL wq pointer, which I suspect happens > if poking_init() is called before workqueue_init_early(), which > allocates system_wq. > > Indeed, in start_kernel(), poking_init() is called before > workqueue_init_early(). > > I'm not sure what are the init order dependencies across subsystems > here. > There is the following order in start_kernel(): > > [...] > mm_core_init(); > poking_init(); > ftrace_init(); > > /* trace_printk can be enabled here */ > early_trace_init(); > > /* > * Set up the scheduler prior starting any interrupts (such > as the > * timer interrupt). Full topology setup happens at > smp_init() > * time - but meanwhile we still have a functioning > scheduler. > */ > sched_init(); > > if (WARN(!irqs_disabled(), > "Interrupts were enabled *very* early, fixing > it\n")) > local_irq_disable(); > radix_tree_init(); > maple_tree_init(); > > /* > * Set up housekeeping before setting up workqueues to allow > the unbound > * workqueue to take non-housekeeping into account. > */ > housekeeping_init(); > > /* > * Allow workqueue creation and work item > queueing/cancelling > * early. Work item execution depends on kthreads and > starts after > * workqueue_init(). > */ > workqueue_init_early(); > [...] > > So either we find a way to reorder this, or we make sure > poking_init() > does not require the workqueue. > > Thanks, > > Mathieu > Nice suggestion! That seems the culprit.. From the full dmesg of the failure I've seen there's also a problem with disabling the delayed work synchronously, since mmdrop cannot sleep if we are not in PREEMPT_RT. I'm trying to come with some satisfactory solution for both, ideally: 1. the delayed work is not needed in early boot, we may have a better place where to start it 2. we can cancel the work asynchronously on mmdrop and abort it if the pcpu_cid is null, but it seems racy, perhaps there's a better place for that too Thanks, Gabriele
On 2025-02-13 08:25, Gabriele Monaco wrote: > On Thu, 2025-02-13 at 14:52 +0800, kernel test robot wrote: >> kernel test robot noticed >> "WARNING:at_kernel/workqueue.c:#__queue_delayed_work" on: >> >> [ 2.640924][ T0] ------------[ cut here ]------------ >> [ 2.641646][ T0] WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:2495 >> __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9)) >> [ 2.642874][ T0] Modules linked in: >> [ 2.643381][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted >> 6.14.0-rc2-00002-g287adf9e9c1f #1 >> [ 2.644582][ T0] Hardware name: QEMU Standard PC (i440FX + >> PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 >> [ 2.645943][ T0] RIP: 0010:__queue_delayed_work >> (kernel/workqueue.c:2495 (discriminator 9)) > > There seem to be major problems with this configuration, I'm trying to > understand what's wrong but, for the time being, this patchset is not > ready for inclusion. Patch 1/3 has been ready for a while though. Can we post it separately for inclusion ? Thanks, Mathieu > > Gabriele >
On Thu, 2025-02-13 at 09:52 -0500, Mathieu Desnoyers wrote: > On 2025-02-13 08:25, Gabriele Monaco wrote: > > On Thu, 2025-02-13 at 14:52 +0800, kernel test robot wrote: > > > kernel test robot noticed > > > "WARNING:at_kernel/workqueue.c:#__queue_delayed_work" on: > > > > > > [ 2.640924][ T0] ------------[ cut here ]------------ > > > [ 2.641646][ T0] WARNING: CPU: 0 PID: 0 at > > > kernel/workqueue.c:2495 > > > __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9)) > > > [ 2.642874][ T0] Modules linked in: > > > [ 2.643381][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not > > > tainted > > > 6.14.0-rc2-00002-g287adf9e9c1f #1 > > > [ 2.644582][ T0] Hardware name: QEMU Standard PC (i440FX + > > > PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 > > > [ 2.645943][ T0] RIP: 0010:__queue_delayed_work > > > (kernel/workqueue.c:2495 (discriminator 9)) > > > > There seem to be major problems with this configuration, I'm trying > > to > > understand what's wrong but, for the time being, this patchset is > > not > > ready for inclusion. > > Patch 1/3 has been ready for a while though. Can we post it > separately > for inclusion ? > I would say so, there's no need to delay it further. Thanks, Gabriele
On 2025-02-13 08:25, Gabriele Monaco wrote: > On Thu, 2025-02-13 at 14:52 +0800, kernel test robot wrote: >> kernel test robot noticed >> "WARNING:at_kernel/workqueue.c:#__queue_delayed_work" on: >> >> [ 2.640924][ T0] ------------[ cut here ]------------ >> [ 2.641646][ T0] WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:2495 >> __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9)) >> [ 2.642874][ T0] Modules linked in: >> [ 2.643381][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted >> 6.14.0-rc2-00002-g287adf9e9c1f #1 >> [ 2.644582][ T0] Hardware name: QEMU Standard PC (i440FX + >> PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 >> [ 2.645943][ T0] RIP: 0010:__queue_delayed_work >> (kernel/workqueue.c:2495 (discriminator 9)) > > There seem to be major problems with this configuration, I'm trying to > understand what's wrong but, for the time being, this patchset is not > ready for inclusion. I'm staring at this now, and I'm thinking we could do a simpler change that would solve your RT issues without having to introduce a dependency on workqueue.c. So if the culprit is that task_mm_cid_work() runs for too long on large many-cpus systems, why not break it up into smaller iterations ? So rather than iterating on "for_each_possible_cpu", we could simply break this down into iteration on at most N cpus, so: tick #1: iteration on CPUs 0 .. N - 1 tick #2: iteration on CPUs N .. 2*N - 1 ... circling back to 0 when it reaches the number of possible cpus. This N value could be configurable, e.g. CONFIG_RSEQ_CID_SCAN_BATCH, with a sane default. An RT system could decide to make that value lower. Then all we need to do is remember which was that last observed cpu number in the mm struct, so the next tick picks up from there. The main downside of this approach compared to scheduling delayed work in a workqueue is that it depends on having the mm be current when the scheduler tick happens. But perhaps this is something we could fix in a different way that does not add a dependency on workqueue. I'm not sure how though. Thoughts ? Thanks, Mathieu
On Thu, 2025-02-13 at 12:31 -0500, Mathieu Desnoyers wrote: > On 2025-02-13 08:25, Gabriele Monaco wrote: > > On Thu, 2025-02-13 at 14:52 +0800, kernel test robot wrote: > > > kernel test robot noticed > > > "WARNING:at_kernel/workqueue.c:#__queue_delayed_work" on: > > > > > > [ 2.640924][ T0] ------------[ cut here ]------------ > > > [ 2.641646][ T0] WARNING: CPU: 0 PID: 0 at > > > kernel/workqueue.c:2495 > > > __queue_delayed_work (kernel/workqueue.c:2495 (discriminator 9)) > > > [ 2.642874][ T0] Modules linked in: > > > [ 2.643381][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not > > > tainted > > > 6.14.0-rc2-00002-g287adf9e9c1f #1 > > > [ 2.644582][ T0] Hardware name: QEMU Standard PC (i440FX + > > > PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 > > > [ 2.645943][ T0] RIP: 0010:__queue_delayed_work > > > (kernel/workqueue.c:2495 (discriminator 9)) > > > > There seem to be major problems with this configuration, I'm trying > > to > > understand what's wrong but, for the time being, this patchset is > > not > > ready for inclusion. > > I'm staring at this now, and I'm thinking we could do a simpler > change > that would solve your RT issues without having to introduce a > dependency > on workqueue.c. > > So if the culprit is that task_mm_cid_work() runs for too long on > large > many-cpus systems, why not break it up into smaller iterations ? > > So rather than iterating on "for_each_possible_cpu", we could simply > break this down into iteration on at most N cpus, so: > > tick #1: iteration on CPUs 0 .. N - 1 > tick #2: iteration on CPUs N .. 2*N - 1 > ... > circling back to 0 when it reaches the number of possible cpus. > > This N value could be configurable, e.g. CONFIG_RSEQ_CID_SCAN_BATCH, > with a sane default. An RT system could decide to make that value > lower. > > Then all we need to do is remember which was that last observed cpu > number in the mm struct, so the next tick picks up from there. > > The main downside of this approach compared to scheduling delayed > work in a workqueue is that it depends on having the mm be current > when > the scheduler tick happens. But perhaps this is something we could > fix > in a different way that does not add a dependency on workqueue. I'm > not > sure how though. > > Thoughts ? Mmh, that's indeed neat, what is not so good about this type of task work is that it's a pure latency, it will happen before scheduling the task and can't be interrupted. The only acceptable latency is a bounded one and your idea is going in that direction. As you mentioned, this will make the compaction of mm_cid even more rare and will likely have the test in 3/3 fail even more often, I'm not sure if this is necessarily a bad thing though, since mm_cid compaction is mainly aesthetic, so we could just increase the duration of the test or even add a busy loop inside to make the task more likely to run this compaction. I gave a thought about this whole thing, don't take this too seriously, but what I see essentially flawed in this approach is: 1. task_works are set on tick 2. task_works are run returning to userspace 1. is the issue with frequency and 2. can be mitigated by your idea, but not essentially solved. What if we (also) did: 1+. set this task_work while switching in 2+. run this task_work while switching out to sleep (i.e. no preemption) 1+. would make sure all threads have this task_work scheduled at a certain point (perhaps a bit too much, but we have a periodicity check in place). 2+. can effectively run the task in a moment when it is not problematic for the real time response: on a preemptible kernel, as soon as a task with higher priority is ready to run, it will preempt the currently running one, the fact current is going to sleep willingly implies there's no higher priority task ready, so likely no task really caring about RT response is going to run after. Not all tasks are ever going to sleep, so we must keep the original TWA_RESUME in the task_work, especially for those long-running or low- priority, both unlikely to be RT tasks. I'm going to try a patch with this CONFIG_RSEQ_CID_SCAN_BATCH and tuning the test to pass. In the future we can see if those ideas make sense and perhaps bring them in. Thanks, Gabriele
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index 0234f14f2aa6b..3aeadb519cac5 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -861,12 +861,6 @@ struct mm_struct { * runqueue locks. */ struct mm_cid __percpu *pcpu_cid; - /* - * @mm_cid_next_scan: Next mm_cid scan (in jiffies). - * - * When the next mm_cid scan is due (in jiffies). - */ - unsigned long mm_cid_next_scan; /** * @nr_cpus_allowed: Number of CPUs allowed for mm. * @@ -889,6 +883,7 @@ struct mm_struct { * mm nr_cpus_allowed updates. */ raw_spinlock_t cpus_allowed_lock; + struct delayed_work mm_cid_work; #endif #ifdef CONFIG_MMU atomic_long_t pgtables_bytes; /* size of all page tables */ @@ -1180,11 +1175,16 @@ static inline void vma_iter_init(struct vma_iterator *vmi, #ifdef CONFIG_SCHED_MM_CID +#define SCHED_MM_CID_PERIOD_NS (100ULL * 1000000) /* 100ms */ +#define MM_CID_SCAN_DELAY 100 /* 100ms */ + enum mm_cid_state { MM_CID_UNSET = -1U, /* Unset state has lazy_put flag set. */ MM_CID_LAZY_PUT = (1U << 31), }; +extern void task_mm_cid_work(struct work_struct *work); + static inline bool mm_cid_is_unset(int cid) { return cid == MM_CID_UNSET; @@ -1257,12 +1257,16 @@ static inline int mm_alloc_cid_noprof(struct mm_struct *mm, struct task_struct * if (!mm->pcpu_cid) return -ENOMEM; mm_init_cid(mm, p); + INIT_DELAYED_WORK(&mm->mm_cid_work, task_mm_cid_work); + schedule_delayed_work(&mm->mm_cid_work, + msecs_to_jiffies(MM_CID_SCAN_DELAY)); return 0; } #define mm_alloc_cid(...) alloc_hooks(mm_alloc_cid_noprof(__VA_ARGS__)) static inline void mm_destroy_cid(struct mm_struct *mm) { + disable_delayed_work_sync(&mm->mm_cid_work); free_percpu(mm->pcpu_cid); mm->pcpu_cid = NULL; } diff --git a/include/linux/sched.h b/include/linux/sched.h index 9632e3318e0d6..515b15f946cac 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1397,7 +1397,6 @@ struct task_struct { int last_mm_cid; /* Most recent cid in mm */ int migrate_from_cpu; int mm_cid_active; /* Whether cid bitmap is active */ - struct callback_head cid_work; #endif struct tlbflush_unmap_batch tlb_ubc; diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 165c90ba64ea9..c65003ab8c55b 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4524,7 +4524,6 @@ static void __sched_fork(unsigned long clone_flags, struct task_struct *p) p->wake_entry.u_flags = CSD_TYPE_TTWU; p->migration_pending = NULL; #endif - init_sched_mm_cid(p); } DEFINE_STATIC_KEY_FALSE(sched_numa_balancing); @@ -5662,7 +5661,6 @@ void sched_tick(void) resched_latency = cpu_resched_latency(rq); calc_global_load_tick(rq); sched_core_tick(rq); - task_tick_mm_cid(rq, donor); scx_tick(rq); rq_unlock(rq, &rf); @@ -10528,38 +10526,17 @@ static void sched_mm_cid_remote_clear_weight(struct mm_struct *mm, int cpu, sched_mm_cid_remote_clear(mm, pcpu_cid, cpu); } -static void task_mm_cid_work(struct callback_head *work) +void task_mm_cid_work(struct work_struct *work) { - unsigned long now = jiffies, old_scan, next_scan; - struct task_struct *t = current; struct cpumask *cidmask; - struct mm_struct *mm; + struct delayed_work *delayed_work = container_of(work, struct delayed_work, work); + struct mm_struct *mm = container_of(delayed_work, struct mm_struct, mm_cid_work); int weight, cpu; - SCHED_WARN_ON(t != container_of(work, struct task_struct, cid_work)); - - work->next = work; /* Prevent double-add */ - if (t->flags & PF_EXITING) - return; - mm = t->mm; - if (!mm) - return; - old_scan = READ_ONCE(mm->mm_cid_next_scan); - next_scan = now + msecs_to_jiffies(MM_CID_SCAN_DELAY); - if (!old_scan) { - unsigned long res; - - res = cmpxchg(&mm->mm_cid_next_scan, old_scan, next_scan); - if (res != old_scan) - old_scan = res; - else - old_scan = next_scan; - } - if (time_before(now, old_scan)) - return; - if (!try_cmpxchg(&mm->mm_cid_next_scan, &old_scan, next_scan)) - return; cidmask = mm_cidmask(mm); + /* Nothing to clear for now */ + if (cpumask_empty(cidmask)) + goto out; /* Clear cids that were not recently used. */ for_each_possible_cpu(cpu) sched_mm_cid_remote_clear_old(mm, cpu); @@ -10570,35 +10547,8 @@ static void task_mm_cid_work(struct callback_head *work) */ for_each_possible_cpu(cpu) sched_mm_cid_remote_clear_weight(mm, cpu, weight); -} - -void init_sched_mm_cid(struct task_struct *t) -{ - struct mm_struct *mm = t->mm; - int mm_users = 0; - - if (mm) { - mm_users = atomic_read(&mm->mm_users); - if (mm_users == 1) - mm->mm_cid_next_scan = jiffies + msecs_to_jiffies(MM_CID_SCAN_DELAY); - } - t->cid_work.next = &t->cid_work; /* Protect against double add */ - init_task_work(&t->cid_work, task_mm_cid_work); -} - -void task_tick_mm_cid(struct rq *rq, struct task_struct *curr) -{ - struct callback_head *work = &curr->cid_work; - unsigned long now = jiffies; - - if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)) || - work->next != work) - return; - if (time_before(now, READ_ONCE(curr->mm->mm_cid_next_scan))) - return; - - /* No page allocation under rq lock */ - task_work_add(curr, work, TWA_RESUME); +out: + schedule_delayed_work(delayed_work, msecs_to_jiffies(MM_CID_SCAN_DELAY)); } void sched_mm_cid_exit_signals(struct task_struct *t) diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 606c96b74ebfa..fc613d9090bed 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -3622,16 +3622,11 @@ extern void sched_dynamic_update(int mode); #ifdef CONFIG_SCHED_MM_CID -#define SCHED_MM_CID_PERIOD_NS (100ULL * 1000000) /* 100ms */ -#define MM_CID_SCAN_DELAY 100 /* 100ms */ - extern raw_spinlock_t cid_lock; extern int use_cid_lock; extern void sched_mm_cid_migrate_from(struct task_struct *t); extern void sched_mm_cid_migrate_to(struct rq *dst_rq, struct task_struct *t); -extern void task_tick_mm_cid(struct rq *rq, struct task_struct *curr); -extern void init_sched_mm_cid(struct task_struct *t); static inline void __mm_cid_put(struct mm_struct *mm, int cid) { @@ -3899,8 +3894,6 @@ static inline void switch_mm_cid(struct rq *rq, static inline void switch_mm_cid(struct rq *rq, struct task_struct *prev, struct task_struct *next) { } static inline void sched_mm_cid_migrate_from(struct task_struct *t) { } static inline void sched_mm_cid_migrate_to(struct rq *dst_rq, struct task_struct *t) { } -static inline void task_tick_mm_cid(struct rq *rq, struct task_struct *curr) { } -static inline void init_sched_mm_cid(struct task_struct *t) { } #endif /* !CONFIG_SCHED_MM_CID */ extern u64 avg_vruntime(struct cfs_rq *cfs_rq);
Currently, the task_mm_cid_work function is called in a task work triggered by a scheduler tick to frequently compact the mm_cids of each process. This can delay the execution of the corresponding thread for the entire duration of the function, negatively affecting the response in case of real time tasks. In practice, we observe task_mm_cid_work increasing the latency of 30-35us on a 128 cores system, this order of magnitude is meaningful under PREEMPT_RT. Run the task_mm_cid_work in a new delayed work connected to the mm_struct rather than in the task context before returning to userspace. This delayed work is initialised while allocating the mm and disabled before freeing it, its execution is no longer triggered by scheduler ticks but run periodically based on the defined MM_CID_SCAN_DELAY. The main advantage of this change is that the function can be offloaded to a different CPU and even preempted by RT tasks. Moreover, this new behaviour could be more predictable with periodic tasks with short runtime, which may rarely run during a scheduler tick. Now, the work is always scheduled with the same periodicity for each mm (though the periodicity is not guaranteed due to interference from other tasks, but mm_cid compaction is mostly best effort). To avoid excessively increased runtime, we quickly return from the function if we have no work to be done (i.e. no mm_cid is allocated). This is helpful for tasks that sleep for a long time, but also for terminated task. We are no longer following the process' state, hence the function continues to run after a process terminates but before its mm is freed. Fixes: 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com> --- include/linux/mm_types.h | 16 ++++++---- include/linux/sched.h | 1 - kernel/sched/core.c | 66 +++++----------------------------------- kernel/sched/sched.h | 7 ----- 4 files changed, 18 insertions(+), 72 deletions(-)