Linus,
Please pull the latest sched/core git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-core-2023-04-27
# HEAD: f31dcb152a3d0816e2f1deab4e64572336da197d sched/clock: Fix local_clock() before sched_clock_init()
Scheduler changes for v6.4:
- Allow unprivileged PSI poll()ing
- Fix performance regression introduced by mm_cid
- Improve livepatch stalls by adding livepatch task switching to cond_resched(),
this resolves livepatching busy-loop stalls with certain CPU-bound kthreads.
- Improve sched_move_task() performance on autogroup configs.
- On core-scheduling CPUs, avoid selecting throttled tasks to run
- Misc cleanups, fixes and improvements.
Thanks,
Ingo
------------------>
Aaron Thompson (1):
sched/clock: Fix local_clock() before sched_clock_init()
Domenico Cerasuolo (4):
sched/psi: Rearrange polling code in preparation
sched/psi: Rename existing poll members in preparation
sched/psi: Extract update_triggers side effect
sched/psi: Allow unprivileged polling of N*2s period
Hao Jia (1):
sched/core: Avoid selecting the task that is throttled to run when core-sched enable
Josh Poimboeuf (5):
livepatch: Convert stack entries array to percpu
livepatch: Skip task_call_func() for current task
livepatch,sched: Add livepatch task switching to cond_resched()
vhost: Fix livepatch timeouts in vhost_worker()
sched/core: Make sched_dynamic_mutex static
Libo Chen (1):
sched/fair: Fix inaccurate tally of ttwu_move_affine
Mathieu Desnoyers (1):
sched: Fix performance regression introduced by mm_cid
Schspa Shi (1):
sched/rt: Fix bad task migration for rt tasks
Shrikanth Hegde (1):
sched: Interleave cfs bandwidth timers for improved single thread performance at low utilization
Tom Rix (1):
sched/topology: Make sched_energy_mutex,update static
wuchi (1):
sched/core: Reduce cost of sched_move_task when config autogroup
Documentation/accounting/psi.rst | 4 +
drivers/vhost/vhost.c | 3 +-
include/linux/livepatch.h | 1 +
include/linux/livepatch_sched.h | 29 ++
include/linux/mm_types.h | 82 ++++-
include/linux/psi.h | 2 +-
include/linux/psi_types.h | 43 +--
include/linux/sched.h | 23 +-
include/linux/sched/mm.h | 5 +
kernel/cgroup/cgroup.c | 2 +-
kernel/fork.c | 9 +-
kernel/livepatch/core.c | 1 +
kernel/livepatch/transition.c | 122 +++++--
kernel/sched/clock.c | 3 +
kernel/sched/core.c | 669 ++++++++++++++++++++++++++++++++++++---
kernel/sched/deadline.c | 11 +
kernel/sched/fair.c | 22 +-
kernel/sched/psi.c | 473 ++++++++++++++-------------
kernel/sched/rt.c | 23 ++
kernel/sched/sched.h | 243 ++++++++++++--
kernel/sched/topology.c | 4 +-
21 files changed, 1424 insertions(+), 350 deletions(-)
create mode 100644 include/linux/livepatch_sched.h
The pull request you sent on Thu, 27 Apr 2023 22:51:05 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-core-2023-04-27
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/586b222d748e91c619d68e9239654ebc7fed9b0c
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Thu, Apr 27, 2023 at 1:51 PM Ingo Molnar <[email protected]> wrote:
>
> - Fix performance regression introduced by mm_cid
This causes a conflict with commit b20b0368c614 ("mm: fix memory leak
on mm_init error handling") that came in through the MM tree.
That conflict is trivial to resolve, and I did so.
Except I also checked my resolution with what was going on in
linux-next, and it's different.
I'm pretty sure the resolution in linux-next is wrong, but I thought
I'd mention this, since clearly this wasn't caught in linux-next.
Or maybe it's me that did it wrong, but hey, that couldn't actually
happen, could it?
Linus
On 2023-04-28 18:02, Linus Torvalds wrote:
> On Thu, Apr 27, 2023 at 1:51 PM Ingo Molnar <[email protected]> wrote:
>>
>> - Fix performance regression introduced by mm_cid
>
> This causes a conflict with commit b20b0368c614 ("mm: fix memory leak
> on mm_init error handling") that came in through the MM tree.
>
> That conflict is trivial to resolve, and I did so.
>
> Except I also checked my resolution with what was going on in
> linux-next, and it's different.
>
> I'm pretty sure the resolution in linux-next is wrong, but I thought
> I'd mention this, since clearly this wasn't caught in linux-next.
>
> Or maybe it's me that did it wrong, but hey, that couldn't actually
> happen, could it?
I've reviewed both merge commits (c79e0731da from next-20230428 and
586b222d74 from master) and I confirm that your conflict resolution
is correct. The one in next was wrong.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
* Mathieu Desnoyers <[email protected]> wrote:
> On 2023-04-28 18:02, Linus Torvalds wrote:
> > On Thu, Apr 27, 2023 at 1:51 PM Ingo Molnar <[email protected]> wrote:
> > >
> > > - Fix performance regression introduced by mm_cid
> >
> > This causes a conflict with commit b20b0368c614 ("mm: fix memory leak
> > on mm_init error handling") that came in through the MM tree.
> >
> > That conflict is trivial to resolve, and I did so.
> >
> > Except I also checked my resolution with what was going on in
> > linux-next, and it's different.
> >
> > I'm pretty sure the resolution in linux-next is wrong, but I thought
> > I'd mention this, since clearly this wasn't caught in linux-next.
> >
> > Or maybe it's me that did it wrong, but hey, that couldn't actually
> > happen, could it?
>
> I've reviewed both merge commits (c79e0731da from next-20230428 and
> 586b222d74 from master) and I confirm that your conflict resolution
> is correct. The one in next was wrong.
Indeed - mm_alloc_cid() happens after the MM context has already been
initialized, so the fail_cid label needs to deinit the context aka call
destroy_context().
So the resolution by Linus is the correct one:
mm_destroy_cid(mm);
fail_cid:
destroy_context(mm);
fail_nocontext:
mm_free_pgd(mm);
Thanks,
Ingo