t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Acked-by: Shuah Khan
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rseq/.gitignor
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Acked-by: Shuah Khan
Signed-off-by: Gabriele Monaco
---
tools/test
2025-06-18T21:04:30Z Shuah Khan :
> On 6/13/25 03:12, Gabriele Monaco wrote:
>> A task in the kernel (task_mm_cid_work) runs somewhat periodically to
>> compact the mm_cid for each process. Add a test to validate that it runs
>> correctly and timely.
>> The test spawns
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rs
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rs
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rs
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rs
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rs
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rs
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rs
On Tue, 2025-02-18 at 16:45 -0700, Shuah Khan wrote:
>
> Please send v6 with the suggested changes. Also change the commit
> summary to
>
> "selftests/rseq"
Sure, will do. There was actually a V6 already, so I'm sending a V7.
In the meanwhile there was a discussion about the approach. I'm going
le.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rseq/.gitignore | 1 +
tools/testing/selftests/rseq/Makefile
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rs
On Mon, 2025-02-10 at 15:53 +0100, Mathieu Desnoyers wrote:
> On 2025-02-10 08:57, Gabriele Monaco wrote:
> > A task in the kernel (task_mm_cid_work) runs somewhat periodically
> > to
> > compact the mm_cid for each process. Add a test to validate that it
> > ru
t happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
To: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rseq/.gitignor
On Fri, 2024-12-13 at 09:14 -0500, Mathieu Desnoyers wrote:
> On 2024-12-13 04:54, Gabriele Monaco wrote:
> > Currently, the task_mm_cid_work function is called in a task work
> > triggered by a scheduler tick. This can delay the execution of the
> > task
> > for
On Fri, 2024-12-13 at 09:29 -0500, Mathieu Desnoyers wrote:
> On 2024-12-13 04:54, Gabriele Monaco wrote:
> > A task in the kernel (task_mm_cid_work) runs somewhat periodically
> > to
> > compact the mm_cid for each process, this test tries to validate
> > that
>
On Fri, 2024-12-13 at 10:54 +0100, Gabriele Monaco wrote:
> OVERHEAD COMPARISON
>
> [..]
>
> I will post another email with the scripts used to retrieve the data
> and
> more details about the runtime distribution.
This message contains the performance results produced by
n't happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
Signed-off-by: Gabriele Monaco
---
tools/testing/selftests/rseq/.gitignore | 1 +
: Improve cache locality of RSEQ concurrency IDs for
intermittent workloads")
Cc: Peter Zijlstra (Intel)
Cc: Marco Elver
Cc: Ingo Molnar
Tested-by: Gabriele Monaco
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Gabriele Monaco
---
include/linux/mm_types.h | 7 ---
kernel/sc
ff-by: Gabriele Monaco
---
include/linux/mm_types.h | 7 ---
kernel/sched/core.c | 19 +++
2 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 92acb827fee4..8a76a1c09234 100644
--- a/include/linux/mm_ty
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 in some
situations since the delayed work is always scheduled with the same
periodicity for each mm.
Signed-off-by: Gabriele
other email with the scripts used to retrieve the data and
more details about the runtime distribution.
[1] -
https://lore.kernel.org/linux-kernel/20241205083110.180134-2-gmon...@redhat.com/
[2] - https://github.com/arighi/virtme-ng
Gabriele Monaco (3):
sched: Move task_mm_cid_work to mm
On Tue, 2024-12-03 at 10:00 -0500, Joel Fernandes wrote:
>
> Also there is no guarantee that RCU callback will run within a thread
> context (example, some configurations run it in softirq). Further,
> call_rcu() usage as shown in this patch can also delay callback runs
> by seconds (with RCU_LA
> I've used the same task work pattern as NUMA here. What makes it
> OK for NUMA and not for mm_cid ?
>
I didn't investigate the behaviour with the NUMA work, but my rough
guess is that this wouldn't even be visible in an isolated environment
(i.e. no migrations).
Also it doesn't seem to scale li
First of all, thanks for the quick reply
> I get that you have this on kunit on ARCH=um, but that makes it
> neither
> a kunit nor a um patch :)
Well, yes I wasn't entirely sure how to put it, sure people from
UM/KUnit know what this is about, but I agree perhaps the patch title
can be a bit mi
.
Moving the inclusion of `asm-generic/iomap.h` fixes it.
Signed-off-by: Gabriele Monaco
---
include/asm-generic/io.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 80de699bf6af..0b02c8e38f20 100644
--- a
27 matches
Mail list logo
