On Wed, May 14, 2025 at 11:51:44AM +0200, Petr Mladek wrote:
> IMHO, it might be easier when it goes via tip. Peter, feel free to
> take it.
Done!
> Reviewed-by: Petr Mladek
> Tested-by: Petr Mladek
For some reason b4 didn't pick up these tags, added them manually and
force pushed it again.
On Fri, May 09 2025 at 13:36, Sebastian Andrzej Siewior wrote:
> From: Peter Zijlstra
>
> With the goal of deprecating / removing VOLUNTARY preempt, live-patch
> needs to stop relying on cond_resched() to make forward progress.
>
> Instead, rely on schedule() with TASK_FREEZABLE set. Just like
> l
On Tue 2025-05-13 15:34:50, Miroslav Benes wrote:
> On Fri, 9 May 2025, Sebastian Andrzej Siewior wrote:
>
> > From: Peter Zijlstra
> >
> > With the goal of deprecating / removing VOLUNTARY preempt, live-patch
> > needs to stop relying on cond_resched() to make forward progress.
> >
> > Instead
On Tue 2025-05-13 16:05:51, Miroslav Benes wrote:
> On Tue, 13 May 2025, Peter Zijlstra wrote:
>
> > On Tue, May 13, 2025 at 03:34:50PM +0200, Miroslav Benes wrote:
> > > Hi,
> > >
> > > thanks for the updated version.
> > >
> > > On Fri, 9 May 2025, Sebastian Andrzej Siewior wrote:
> > >
> > >
On Fri, May 09, 2025 at 01:36:59PM +0200, Sebastian Andrzej Siewior wrote:
> From: Peter Zijlstra
>
> With the goal of deprecating / removing VOLUNTARY preempt, live-patch
> needs to stop relying on cond_resched() to make forward progress.
>
> Instead, rely on schedule() with TASK_FREEZABLE set.
On Tue, May 13, 2025 at 03:34:50PM +0200, Miroslav Benes wrote:
> Hi,
>
> thanks for the updated version.
>
> On Fri, 9 May 2025, Sebastian Andrzej Siewior wrote:
>
> > From: Peter Zijlstra
> >
> > With the goal of deprecating / removing VOLUNTARY preempt, live-patch
> > needs to stop relying
On Tue, 13 May 2025, Peter Zijlstra wrote:
> On Tue, May 13, 2025 at 03:34:50PM +0200, Miroslav Benes wrote:
> > Hi,
> >
> > thanks for the updated version.
> >
> > On Fri, 9 May 2025, Sebastian Andrzej Siewior wrote:
> >
> > > From: Peter Zijlstra
> > >
> > > With the goal of deprecating / r
Hi,
thanks for the updated version.
On Fri, 9 May 2025, Sebastian Andrzej Siewior wrote:
> From: Peter Zijlstra
>
> With the goal of deprecating / removing VOLUNTARY preempt, live-patch
> needs to stop relying on cond_resched() to make forward progress.
>
> Instead, rely on schedule() with TA
comments in __klp_sched_try_switch()
- Replaced unlikely with likely in __klp_sched_try_switch()
- Dropped RFC
include/linux/livepatch_sched.h | 14 -
include/linux/sched.h | 6
kernel/livepatch/transition.c | 52 ++---
kernel/sched/core.c
nst struct mptcp_addr_info *info,
struct sockaddr_storage *addr,
unsigned short family);
struct mptcp_sched_ops *mptcp_sched_find(const char *name);
+int mptcp_validate_scheduler(struct mptcp_sched_ops *sched);
int mptcp_register_scheduler(struct mptcp
This is a follow-up of commit b68b106b0f15 ("mptcp: sched: reduce size
for unused data"), now removing the mptcp_sched_data structure.
Now is a good time to do that, because the previously mentioned WIP work
has been updated, no longer depending on this structure.
Signed-off-by: Matth
> +++ b/net/mptcp/protocol.h
> @@ -744,6 +744,7 @@ void mptcp_info2sockaddr(const struct
> mptcp_addr_info *info,
> struct sockaddr_storage *addr,
> unsigned short family);
> struct mptcp_sched_ops *mptcp_sched_find(const char *name);
>
Hi Geliang,
On 11/04/2025 15:57, Geliang Tang wrote:
> Hi Matt,
>
> On Fri, 2025-04-11 at 13:04 +0200, Matthieu Baerts (NGI0) wrote:
>> From: Geliang Tang
>
> Please update my email as "Geliang Tang " here
> and in patch 7, otherwise, CI will complain that the email address
> after "From: " is
This is a follow-up of commit b68b106b0f15 ("mptcp: sched: reduce size
for unused data"), now removing the mptcp_sched_data structure.
Now is a good time to do that, because the previously mentioned WIP work
has been updated, no longer depending on this structure.
Signed-off-by: Matth
struct sockaddr_storage *addr,
unsigned short family);
struct mptcp_sched_ops *mptcp_sched_find(const char *name);
+int mptcp_validate_scheduler(struct mptcp_sched_ops *sched);
int mptcp_register_scheduler(struct mptcp_sched_ops *sched);
void mptcp_unregister_schedu
> void __klp_sched_try_switch(void)
> {
> - if (likely(!klp_patch_pending(current)))
> - return;
> -
> /*
>* This function is called from cond_resched() which is called in many
>* places throughout the kernel. Using the klp_mutex here might
> @@ -377,14 +365
On Wed, Mar 26, 2025 at 03:37:50PM +0100, Miroslav Benes wrote:
> If I remember correctly, we had something like this in the old kGraft
> implementation of the live patching (SUSE way). We exactly had a hook
> somewhere in the kthread freezing code. This looks much cleaner and as far
> as I kno
On Wed, 26 Mar 2025, Peter Zijlstra wrote:
> On Wed, Mar 26, 2025 at 03:37:50PM +0100, Miroslav Benes wrote:
>
> > If I remember correctly, we had something like this in the old kGraft
> > implementation of the live patching (SUSE way). We exactly had a hook
> > somewhere in the kthread freezin
> > > Compile tested only.
> > >
> > > Signed-off-by: Peter Zijlstra (Intel)
> > > ---
> > > include/linux/livepatch_sched.h | 15 +
> > > include/linux/sched.h | 6 -
> > > kernel/livepatch/transition.c | 30 ++-
| 30 ++---
> kernel/sched/core.c | 50
> +++--
> 4 files changed, 21 insertions(+), 80 deletions(-)
>
> diff --git a/include/linux/livepatch_sched.h b/include/linux/livepatch_sched.h
> index 013794fb5da0.
include/linux/livepatch_sched.h | 15 +
> > include/linux/sched.h | 6 -----
> > kernel/livepatch/transition.c | 30 ++---
> > kernel/sched/core.c | 50
> > +++--
> > 4 files cha
tested only.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/livepatch_sched.h | 15 +
include/linux/sched.h | 6 -
kernel/livepatch/transition.c | 30 ++---
kernel/sched/core.c | 50 +++--
4
t; > throttling should allow RT tasks to starve anything it wants. And some RT
> > > applications rely on this.
> > >
> > > Should this include a Fixes and Cc stable?
> >
> > Yeah that makes sense to me, I'll include the Fixes tag in the v2.
&g
Hmm, I wonder if dl_server caused a regression. That is, disabling rt
> > throttling should allow RT tasks to starve anything it wants. And some RT
> > applications rely on this.
> >
> > Should this include a Fixes and Cc stable?
>
> Yeah that makes sense to m
On Tue, Mar 04, 2025 at 03:06:32PM -0500, Steven Rostedt wrote:
> On Tue, 4 Mar 2025 15:01:16 -0500
> Joel Fernandes wrote:
>
> > Currently, RCU boost testing in rcutorture is broken because it relies on
> > having RT throttling disabled. This means the test will always pass (or
> > rarely fail)
task_non_contending() because otherwise it
throws a warning (in the case when DL server was already started before
rcutorture started).
Signed-off-by: Joel Fernandes
---
kernel/sched/deadline.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched
On 2/26/25 01:39, Sinadin Shan wrote:
> For kernels with CONFIG_SCHED_CORE=n, the sched selftest cs_prctl_test
> fails with "Not a core sched system" error. Change this to gracefully
> skip the test for systems with core scheduling disabled. Exiting early
> would also ensur
On 2/26/25 01:39, Sinadin Shan wrote:
For kernels with CONFIG_SCHED_CORE=n, the sched selftest cs_prctl_test
fails with "Not a core sched system" error. Change this to gracefully
skip the test for systems with core scheduling disabled. Exiting early
would also ensure failures r
For kernels with CONFIG_SCHED_CORE=n, the sched selftest cs_prctl_test
fails with "Not a core sched system" error. Change this to gracefully
skip the test for systems with core scheduling disabled. Exiting early
would also ensure failures reported in obtaining cookie are valid
failur
The sched tests are missing a target entry and hence out-of-tree build
support.
For instance:
make -C tools/testing/selftests install INSTALL_PATH=/foo/bar
is expected to build the sched tests and place them at /foo/bar.
But this is not observed since a TARGET entry is not present for sched
This patch series introduces changes to add default build support for
the sched tests in selftests.
The only test under sched is cs_prctl_test which validates cookies when
core scheduling is in effect. This test fails on systems where core
scheduling is disabled. The patch series also modifies
On 25-02-2025 04:32 am, Chris Hyser wrote:
From: Sinadin Shan
Sent: Monday, February 24, 2025 7:10 AM
To: Shrikanth Hegde; sh...@kernel.org
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org; Chris Hyser
Subject: Re: [PATCH v2 2/2] selftests: sched: skip cs_prctl_test for
>From: Sinadin Shan
>Sent: Monday, February 24, 2025 7:10 AM
>To: Shrikanth Hegde; sh...@kernel.org
>Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org; Chris Hyser
>Subject: Re: [PATCH v2 2/2] selftests: sched: skip cs_prctl_test for systems
>with core schedul
On 24-02-2025 01:49 pm, Shrikanth Hegde wrote:
On 2/21/25 17:27, Sinadin Shan wrote:
For kernels with CONFIG_SCHED_CORE=n, the sched selftest cs_prctl_test
fails with "Not a core sched system" error. Change this to gracefully
skip the test for systems with core scheduling disable
On 2/21/25 17:27, Sinadin Shan wrote:
For kernels with CONFIG_SCHED_CORE=n, the sched selftest cs_prctl_test
fails with "Not a core sched system" error. Change this to gracefully
skip the test for systems with core scheduling disabled. Exiting early
would also ensure failures r
For kernels with CONFIG_SCHED_CORE=n, the sched selftest cs_prctl_test
fails with "Not a core sched system" error. Change this to gracefully
skip the test for systems with core scheduling disabled. Exiting early
would also ensure failures reported in obtaining cookie are valid
failures a
The sched tests are missing a target entry and hence out-of-tree build
support.
For instance:
make -C tools/testing/selftests install INSTALL_PATH=/foo/bar
is expected to build the sched tests and place them at /foo/bar.
But this is not observed since a TARGET entry is not present for sched
This patch series introduces changes to add default build support for
the sched tests in selftests.
The only test under sched is cs_prctl_test which validates cookies when
core scheduling is in effect. This test fails on systems where core
scheduling is disabled. The patch series also modifies
On 21-02-2025 11:30 am, Chris Hyser wrote:
From: Chris Hyser
Sent: Thursday, February 20, 2025 11:21 PM
To: Sinadin Shan; Shrikanth Hegde
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org;
sh...@kernel.org
Subject: Re: [PATCH] selftests: sched: add sched as a default
From: Chris Hyser
Sent: Thursday, February 20, 2025 11:21 PM
To: Sinadin Shan; Shrikanth Hegde
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org;
sh...@kernel.org
Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
>
> From: Sinadin Shan
From: Sinadin Shan
Sent: Thursday, February 20, 2025 11:23 AM
To: Chris Hyser; Shrikanth Hegde
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org;
sh...@kernel.org
Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
>> I guess my question is w
On 20-02-2025 09:26 pm, Chris Hyser wrote:
From: Sinadin Shan
Sent: Thursday, February 20, 2025 9:52 AM
To: Shrikanth Hegde; Chris Hyser
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org;
sh...@kernel.org
Subject: Re: [PATCH] selftests: sched: add sched as a default selftest
From: Sinadin Shan
Sent: Thursday, February 20, 2025 9:52 AM
To: Shrikanth Hegde; Chris Hyser
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org;
sh...@kernel.org
Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
> On 20-02-2025 01:15 pm, Shrika
On 20-02-2025 01:15 pm, Shrikanth Hegde wrote:
On 2/19/25 12:16, Sinadin Shan wrote:
The sched tests are missing a target entry and hence out-of-tree build
support.
For instance:
make -C tools/testing/selftests install INSTALL_LOCATION=/foo/bar
is expected to build the sched tests and place
On 2/19/25 12:16, Sinadin Shan wrote:
The sched tests are missing a target entry and hence out-of-tree build
support.
For instance:
make -C tools/testing/selftests install INSTALL_LOCATION=/foo/bar
is expected to build the sched tests and place them at /foo/bar.
But this is not observed
> From: Sinadin Shan
> Sent: Wednesday, February 19, 2025 1:46 AM
> To: sh...@kernel.org
> Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org; Chris
> Hyser; Sinadin Shan
> Subject: [PATCH] selftests: sched: add sched as a default selftest target
>
> The s
The sched tests are missing a target entry and hence out-of-tree build
support.
For instance:
make -C tools/testing/selftests install INSTALL_LOCATION=/foo/bar
is expected to build the sched tests and place them at /foo/bar.
But this is not observed since a TARGET entry is not present for sched
From: Ankur Arora
Update comment in __cond_resched() clarifying how urgently needed
quiescent state are provided.
Signed-off-by: Ankur Arora
Reviewed-by: Frederic Weisbecker
Signed-off-by: Paul E. McKenney
---
kernel/sched/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
On 1/29/25 09:52, Sebastian Andrzej Siewior wrote:
> On 2025-01-27 13:22:17 [+0100], Petr Pavlu wrote:
>> On 1/24/25 18:49, Sebastian Andrzej Siewior wrote:
>>> On 2025-01-13 12:09:27 [+0100], Petr Pavlu wrote:
Thanks for this cleanup. I've queued the fix in patch #1 on
modules-fixes. For
On 2025-01-27 13:22:17 [+0100], Petr Pavlu wrote:
> On 1/24/25 18:49, Sebastian Andrzej Siewior wrote:
> > On 2025-01-13 12:09:27 [+0100], Petr Pavlu wrote:
> >> Thanks for this cleanup. I've queued the fix in patch #1 on
> >> modules-fixes. For the rest, I plan to give folks more time to look at
>
On 1/24/25 18:49, Sebastian Andrzej Siewior wrote:
> On 2025-01-13 12:09:27 [+0100], Petr Pavlu wrote:
>> Thanks for this cleanup. I've queued the fix in patch #1 on
>> modules-fixes. For the rest, I plan to give folks more time to look at
>> the changes as this affects a number of subsystems. If t
On 2025-01-13 12:09:27 [+0100], Petr Pavlu wrote:
> Thanks for this cleanup. I've queued the fix in patch #1 on
> modules-fixes. For the rest, I plan to give folks more time to look at
> the changes as this affects a number of subsystems. If there are no
> other concerns, I'd then add the series on
From: Ankur Arora
Update comment in __cond_resched() clarifying how urgently needed
quiescent state are provided.
Signed-off-by: Ankur Arora
Reviewed-by: Frederic Weisbecker
Signed-off-by: Paul E. McKenney
---
kernel/sched/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
On 2025-01-13 12:09:27 [+0100], Petr Pavlu wrote:
> Thanks for this cleanup. I've queued the fix in patch #1 on
> modules-fixes. For the rest, I plan to give folks more time to look at
> the changes as this affects a number of subsystems. If there are no
> other concerns, I'd then add the series on
On 1/8/25 10:04, Sebastian Andrzej Siewior wrote:
> This is an updated version of the initial post after PeterZ made me
> aware that there are users outside of the module directory.
> The goal is replace the mix auf rcu_read_lock(), rcu_read_lock_sched()
> and preempt_disable() with just rcu_read_l
respectively?
>
> Good point! How is the following updated version?
That's exactly what I had in mind, thanks!
Acked-by: Will Deacon
Will
> ---
> From: Frederic Weisbecker
> Date: Fri, 27 Sep 2024 00:48:59 +0200
> Subject: [PATCH 2/2] sched,arm64: Handle CPU isolatio
The list module_bug_list relies on module_mutex for writer
synchronisation. The list is already RCU style.
The list removal is synchronized with modules' synchronize_rcu() in
free_module().
Use RCU read lock protection instead of RCU-sched.
Cc: Andrew Morton
Acked-by: Peter Zijlstra (
The RCU usage in module was introduced in commit d72b37513cdfb ("Remove
stop_machine during module load v2") and it claimed not to be RCU but
similar. Then there was another improvement in commit e91defa26c527
("module: don't use stop_machine on module load"). It become a
5102.hrywu...@linutronix.de/
- Split into smaller patches.
- Converted all users.
Sebastian Andrzej Siewior (28):
module: Extend the preempt disabled section in
dereference_symbol_descriptor().
module: Begin to move from RCU-sched to RCU.
module: Use proper RCU assignment in add_kallsyms().
m
On 2025-01-02 13:47:06 [+0100], Christophe Leroy wrote:
> Hi Sebastian,
Hi Christophe,
> How did you generate that cover letter ?
>
> It should contain the full list of files modified by the series, so that I
> can see if any of them is of interest to me without going into each patch.
>
> This i
On Fri, Dec 20, 2024 at 06:41:14PM +0100, Sebastian Andrzej Siewior wrote:
> Hi,
>
> This is an updated version of the inital post after PeterZ made me aware
> that there are users outside of the module directory.
> The goal is replace the mix auf rcu_read_lock(), rcu_read_lock_sched()
> and preem
g 'cpu_possible_mask' and
> housekeeping_cpumask(HK_TYPE_TICK) for the 'mask' argument respectively?
Good point! How is the following updated version?
---
From: Frederic Weisbecker
Date: Fri, 27 Sep 2024 00:48:59 +0200
Subject: [PATCH 2/2] sched,arm64: Handle CPU isolation on l
ederic Weisbecker
> ---
> arch/arm64/include/asm/cpufeature.h | 1 +
> arch/arm64/include/asm/mmu_context.h | 2 ++
> arch/arm64/kernel/cpufeature.c | 11 +++
> include/linux/mmu_context.h | 1 +
> kernel/sched/core.c | 2 +-
> 5 fi
Hi Sebastian,
Le 20/12/2024 à 18:41, Sebastian Andrzej Siewior a écrit :
Hi,
This is an updated version of the inital post after PeterZ made me aware
that there are users outside of the module directory.
The goal is replace the mix auf rcu_read_lock(), rcu_read_lock_sched()
and preempt_disable(
Hi,
This is an updated version of the inital post after PeterZ made me aware
that there are users outside of the module directory.
The goal is replace the mix auf rcu_read_lock(), rcu_read_lock_sched()
and preempt_disable() with just rcu_read_lock().
I've splitted it into smaller chunks which can
The list module_bug_list relies on module_mutex for writer
synchronisation. The list is already RCU style.
The list removal is synchronized with modules' synchronize_rcu() in
free_module().
Use RCU read lock protection instead of RCU-sched.
Cc: Andrew Morton
Signed-off-by: Sebastian An
The RCU usage in module was introduced in commit d72b37513cdfb ("Remove
stop_machine during module load v2") and it claimed not to be RCU but
similar. Then there was another improvement in commit e91defa26c527
("module: don't use stop_machine on module load"). It become a
n introduced in [2].
>
> [1] https://lore.kernel.org/all/20240913214205.12359-2-frede...@kernel.org/
> [2]
> https://lore.kernel.org/all/169972295552.3135.1094880886431606890.tip-bot2@tip-bot2/
> Reported-by: Vlad Poenaru
> Signed-off-by: Usama Arif
> ---
> kernel/sch
feedback on how this could be reproduced, if the RFC makes sense
or if there is another way to solve this.
Thanks!
[1] https://lore.kernel.org/all/20240913214205.12359-2-frede...@kernel.org/
[2]
https://lore.kernel.org/all/169972295552.3135.1094880886431606890.tip-bot2@tip-bot2/
Usama Arif (1)
l.org/all/20240913214205.12359-2-frede...@kernel.org/
[2]
https://lore.kernel.org/all/169972295552.3135.1094880886431606890.tip-bot2@tip-bot2/
Reported-by: Vlad Poenaru
Signed-off-by: Usama Arif
---
kernel/sched/completion.c | 25 -
1 file changed, 24 insertions(+), 1 deletion
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 the entire duration of the functi
ched.h| 1 -
kernel/sched/core.c | 51 ++------
kernel/sched/sched.h | 7 --
4 files changed, 18 insertions(+), 52 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 7361a8f3ab68..92acb827fee4 100644
--- a/inclu
it as a fix.
Thanks,
Mathieu
However, the change introduced by:
commit 7e019dcc470f ("sched: Improve cache locality of RSEQ concurrency
IDs for intermittent workloads")
adds a per-mm/CPU recent_cid which is never unset unless a thread
migrates.
This is a tradeoff between:
A)
nates but before its
mm is freed.
Can you fold it in patch 1/4 ?
Thanks,
Mathieu
Signed-off-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_ty
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 my scripts, which are
at
From: Mathieu Desnoyers
When a process reduces its number of threads or clears bits in its CPU
affinity mask, the mm_cid allocation should eventually converge towards
smaller values.
However, the change introduced by:
commit 7e019dcc470f ("sched: Improve cache locality of RSEQ concurrenc
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
Monaco
---
include/linux/mm_types.h | 11 +
include/linux/sched.h| 1 -
kernel/sched/core.c | 51 ++--
kernel/sched/sched.h | 7 --
4 files changed, 18 insertions(+), 52 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux
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
emote root partition creation
> problem") introduces a simplified scheme of including only partition
> roots in sched domain generation. However, it does not properly account
> for this exception case. This can result in leakage of isolated CPUs
> into a sched domain.
>
> F
m64/kernel/cpufeature.c | 11 +++
include/linux/mmu_context.h | 1 +
kernel/sched/core.c | 2 +-
5 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 8b4e5a3cd24c..cac5efc83
uding only partition
roots in sched domain generation. However, it does not properly account
for this exception case. This can result in leakage of isolated CPUs
into a sched domain.
Fix it by making sure that isolated CPUs are excluded from the top
cpuset before generating sched domains.
Also update t
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
On Mon, Dec 2, 2024 at 9:34 AM Mathieu Desnoyers
wrote:
>
> += CC RCU maintainers, reviewers and list.
> += RSEQ maintainers.
>
> On 2024-12-02 09:07, 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
t; > CONFIG_PREEMPT_BUILD=y
> > > -CONFIG_PREEMPT_NONE=y
> > > +CONFIG_ARCH_HAS_PREEMPT_LAZY=y
> > > +# CONFIG_PREEMPT_NONE is not set
> > > # CONFIG_PREEMPT_VOLUNTARY is not set
> > > # CONFIG_PREEMPT is not set
> > > +CONFIG_PREEMPT_LAZY=y
>
ere is likely a characteristic
of the call_rcu worker threads that we want to import into
task_tick_mm_cid(), or change task_work.c to add a new flag
that says the work can be dispatched to any CPU.
Signed-off-by: Gabriele Monaco
---
include/linux/sched.h | 1 -
kernel/sched/core.c | 17 ++--
t OK to re-use the task struct rcu field ? Where else is it
> used, and is there a risk of being inserted twice ?
>
The same approach is used in
https://elixir.bootlin.com/linux/v6.12/source/include/linux/sched/task.h#L169
also there it was probably chosen for its simplicity and it isn't the
TARY is not set
> > # CONFIG_PREEMPT is not set
> > +CONFIG_PREEMPT_LAZY=y
> > # CONFIG_PREEMPT_RT is not set
> > CONFIG_PREEMPT_COUNT=y
> > CONFIG_PREEMPTION=y
> >
> …
> > commit: 476e8583ca16eecec0a3a28b6ee7130f4e369389 ("sched, x86: Enable
T_NONE=y
> +CONFIG_ARCH_HAS_PREEMPT_LAZY=y
> +# CONFIG_PREEMPT_NONE is not set
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> +CONFIG_PREEMPT_LAZY=y
> # CONFIG_PREEMPT_RT is not set
> CONFIG_PREEMPT_COUNT=y
> CONFIG_PREEMPTION=y
>
…
> co
Weisbecker
---
arch/arm64/include/asm/cpufeature.h | 1 +
arch/arm64/include/asm/mmu_context.h | 2 ++
arch/arm64/kernel/cpufeature.c | 49 +++-
include/linux/mmu_context.h | 1 +
kernel/sched/core.c | 2 +-
5 files changed, 46 insert
lock when listing packets schedulers. A fix
> for >= 6.10.
>
> [...]
Here is the summary with links:
- [net,1/3] mptcp: init: protect sched with rcu_read_lock
https://git.kernel.org/netdev/net/c/3deb12c788c3
- [net,2/3] mptcp: remove unneeded lock when listing scheds
(no
Weisbecker
---
arch/arm64/include/asm/cpufeature.h | 1 +
arch/arm64/include/asm/mmu_context.h | 2 ++
arch/arm64/kernel/cpufeature.c | 47 +++-
include/linux/mmu_context.h | 1 +
kernel/sched/core.c | 2 +-
5 files changed, 45 insert
Le Mon, Oct 28, 2024 at 04:25:15PM +, Will Deacon a écrit :
> > If nohz_full= isn't used then
> > it's cpu_possible_mask). If there is a housekeeping CPU supporting el0
> > 32bits
> > then it will be disallowed to be ever offlined. But if the first mismatching
> > CPU supporting el0 that pops
Hi Frederic,
Thanks for having a crack at this, but I'm pretty confused now so please
prepare for a bunch of silly questions!
On Tue, Oct 15, 2024 at 03:48:55PM +0200, Frederic Weisbecker wrote:
> Le Tue, Oct 08, 2024 at 11:54:35AM +0100, Will Deacon a écrit :
> > On Fri, Sep 27, 2024 at 12:48:59
rch/x86/entry/common.c:52 (discriminator 1))
>entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
>
> That's because when the socket is initialised, rcu_read_lock() is not
> used despite the explicit comment written above the declaration of
> mptcp_sched_find() in sch
Hi Johannes,
On Tue, 22 Oct 2024 at 19:36, Johannes Weiner wrote:
>
> On Tue, Oct 22, 2024 at 05:51:58PM +0530, Pintu Kumar wrote:
> > There is a psi module that exists under kernel/sched/psi.
> > Add a basic test to test the psi.
>
> I'm not sure this is a valuable
On Tue, Oct 22, 2024 at 05:51:58PM +0530, Pintu Kumar wrote:
> There is a psi module that exists under kernel/sched/psi.
> Add a basic test to test the psi.
I'm not sure this is a valuable use of test cycles. The mere existence
and basic format of the files is very unlikely to be bugg
There is a psi module that exists under kernel/sched/psi.
Add a basic test to test the psi.
This test just add the basic support to check cpu/memory/io interface.
Further test will be added on top of this.
Signed-off-by: Pintu Kumar
---
MAINTAINERS | 2 +
tools
e the declaration of
mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the
warning.
Fixes: 1730b2b2c5a5 ("mptcp: add sched in mptcp_sock")
Cc: sta...@vger.kernel.org
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/523
Reviewed-by: Geliang Tang
Signed-o
MPTCP selftests to cover more code.
Signed-off-by: Matthieu Baerts (NGI0)
---
Matthieu Baerts (NGI0) (3):
mptcp: init: protect sched with rcu_read_lock
mptcp: remove unneeded lock when listing scheds
selftests: mptcp: list sysctl data
net/mptcp/prot
1 - 100 of 9768 matches
Mail list logo
