[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e058fcbd-dc30-4e7e-b54b-969d9dd67d4a@linux.ibm.com>
Date: Mon, 30 Sep 2024 10:39:17 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
linux-kernel@...r.kernel.org
Cc: Ingo Molnar <mingo@...hat.com>, John Ogness <john.ogness@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH 0/3] Allow to enable PREEMPT_RT.
On 9/6/24 16:29, Sebastian Andrzej Siewior wrote:
> The printk bits required for PREEMPT_RT are sitting in linux-next. This
> was the last known roadblock for PREEMPT_RT. The RT queue has
> additionally the "atomic console" for the 8250 UART which is not yet in
> linux-next. This means "legacy console" behaviour as in no printing from
> atomic context in emergency cases. The 8250 UART driver is the only one
> providing "atomic console" support as of today.
>
> With the printk bits merged, PREEMPT_RT could be enabled on X86, ARM64
> and Risc-V. These three architectures merged required changes over the
> years leaving me in a position where I have no essential changes in the
> queue that would affect them.
> ARM and POWERPC have a few essential patches left and I lost track of
> MIPS.
Hi Sebastian.
Congratulations to all PREEMPT_RT developers
and Thank you for sharing detailed info on what went through/in preempt rt over the years.
Used the latest tip/master tree for preempt_rt experiment.
tip/master was at this commit.
commit f441318ec664d99d7cb03b08557ed3b04d9af67f (origin/master, origin/HEAD)
Merge: d73d270676d8 408eb7417a92
Author: Ingo Molnar <mingo@...nel.org>
Date: Wed Sep 25 12:33:39 2024 +0200
Merge branch into tip/master: 'x86/splitlock'
Added the ARCH_SUPPORTS_RT in arch/powerpc/Kconfig. Selected the preempt_rt in menuconfig.
It *compiled and booted successfully* on POWERPC/ppc64le.
Occasionally below sched_warning is seen. It is seen with preempt=full too. So it is likely generic scheduler one,
Not related to RT. I will work on it and try to figure it out.
se->on_rq
WARNING: CPU: 147 PID: 3946 at kernel/sched/fair.c:5629 pick_next_entity+0x140/0x17c
NIP [c0000000001c1fa8] pick_next_entity+0x140/0x17c
LR [c0000000001c1fa4] pick_next_entity+0x13c/0x17c
Call Trace:
[c0000019f7097940] [c0000000001c1fa4] pick_next_entity+0x13c/0x17c (unreliable)
[c0000019f70979c0] [c0000000001c2044] pick_task_fair+0x60/0x128
[c0000019f7097a00] [c0000000001c76ac] pick_next_task_fair+0x68/0x434
[c0000019f7097a90] [c0000000001a7388] __pick_next_task+0x64/0x26c
[c0000019f7097ae0] [c000000000ff62f0] __schedule+0x138/0x73c
[c0000019f7097bb0] [c000000000ff699c] schedule+0x4c/0x114
[c0000019f7097c20] [c0000000005f3624] pipe_read+0x44c/0x5fc
[c0000019f7097d10] [c0000000005e385c] vfs_read+0x2dc/0x3b0
[c0000019f7097dc0] [c0000000005e4884] ksys_read+0xf4/0x144
[c0000019f7097e10] [c0000000000316f8] system_call_exception+0x128/0x360
[c0000019f7097e50] [c00000000000cedc] system_call_vectored_common+0x15c/0x2ec
--- interrupt: 3000 at 0x7fffabcb3cf4
No panic/crash was observed when running some of the microbenchmarks and few real life workloads.
Performance numbers are slightly less than preempt=none. That's likely expected.
However cyclictest numbers are a bit higher with preempt_rt compared to preempt=none.
That probably indicates there are some patches that are yet to be done.
So, Curious to know what are those patches that are left for POWERPC?
would like to work on those and get it enabled on POWERPC.
>
> Sebastian
>
>
Powered by blists - more mailing lists