Message ID | 20230120121856.1407369-1-sudeep.holla@arm.com |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] cacheinfo/arch_topology: Updates for v6.3 | expand |
On Fri, Jan 20, 2023 at 12:18:56PM +0000, Sudeep Holla wrote: > Hi Greg, > > Please pull ! > > It has been tested on RISC-V which is the main users outside of arm64. > The ACPI the RISC-V parts are acked-by the respective maintainers. All > the changes are in the -next for sometime and no issues reported at this > time. > > Regards, > Sudeep > > -->8 > > The following changes since commit 1b929c02afd37871d5afb9d498426f83432e71c2: > > Linux 6.2-rc1 (2022-12-25 13:41:39 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/archtopo-cacheinfo-updates-6.3 Pulled and pushed out, thanks. greg k-h
Hi Sudeep, On Fri, Jan 20, 2023 at 1:22 PM Sudeep Holla <sudeep.holla@arm.com> wrote: > It has been tested on RISC-V which is the main users outside of arm64. Has it? > The ACPI the RISC-V parts are acked-by the respective maintainers. All > the changes are in the -next for sometime and no issues reported at this > time. > > Regards, > Sudeep > > -->8 > > The following changes since commit 1b929c02afd37871d5afb9d498426f83432e71c2: > > Linux 6.2-rc1 (2022-12-25 13:41:39 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/archtopo-cacheinfo-updates-6.3 > > for you to fetch changes up to 198102c9103fc78d8478495971947af77edb05c1: > > cacheinfo: Fix shared_cpu_map to handle shared caches at different levels (2023-01-18 09:58:40 +0000) > > ---------------------------------------------------------------- > cacheinfo and arch_topology updates for v6.3 > > The main change is to build the cache topology information for all > the CPUs from the primary CPU. Currently the cacheinfo for secondary CPUs > is created during the early boot on the respective CPU itself. Preemption > and interrupts are disabled at this stage. On PREEMPT_RT kernels, allocating > memory and even parsing the PPTT table for ACPI based systems triggers a: > 'BUG: sleeping function called from invalid context' > > To prevent this bug, the cacheinfo is now allocated from the primary CPU > when preemption and interrupts are enabled and before booting secondary > CPUs. The cache levels/leaves are computed from DT/ACPI PPTT information > only, without relying on any architecture specific mechanism if done so > early. > > The other minor change included here is to handle shared caches at > different levels when not all the CPUs on the system have the same > cache hierarchy. While this gets rid of the "cacheinfo: Unable to detect cache hierarchy for CPU N" warnings printed during boot, it resurrects the printing of Early cacheinfo failed, ret = -12 during early boot on all my RV64 platforms See also https://lore.kernel.org/all/CAMuHMdUBZ791fxCPkKQ6HCwLE4GJB2S35QC=SQ+X8w5Q4C_70g@mail.gmail.com/ for a similar earlier version triggering the same issue. > ---------------------------------------------------------------- > Pierre Gondois (6): > arch_topology: Build cacheinfo from primary CPU Reverting commit 5944ce092b97caed ("arch_topology: Build cacheinfo from primary CPU") fixes the issue. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tue, Jan 24, 2023 at 02:44:10PM +0100, Geert Uytterhoeven wrote: > Hi Sudeep, > > On Fri, Jan 20, 2023 at 1:22 PM Sudeep Holla <sudeep.holla@arm.com> wrote: > > It has been tested on RISC-V which is the main users outside of arm64. > > Has it? > Hmm, I might have mixed up things then. I was on a vacation for quite some time and might have assumed Conor response on the thread with testing. Extremely sorry for that. However it was in -next for few days before Greg applied to his tree. > > The ACPI the RISC-V parts are acked-by the respective maintainers. All > > the changes are in the -next for sometime and no issues reported at this > > time. > > > > Regards, > > Sudeep > > > > -->8 > > > > The following changes since commit 1b929c02afd37871d5afb9d498426f83432e71c2: > > > > Linux 6.2-rc1 (2022-12-25 13:41:39 -0800) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/archtopo-cacheinfo-updates-6.3 > > > > for you to fetch changes up to 198102c9103fc78d8478495971947af77edb05c1: > > > > cacheinfo: Fix shared_cpu_map to handle shared caches at different levels (2023-01-18 09:58:40 +0000) > > > > ---------------------------------------------------------------- > > cacheinfo and arch_topology updates for v6.3 > > > > The main change is to build the cache topology information for all > > the CPUs from the primary CPU. Currently the cacheinfo for secondary CPUs > > is created during the early boot on the respective CPU itself. Preemption > > and interrupts are disabled at this stage. On PREEMPT_RT kernels, allocating > > memory and even parsing the PPTT table for ACPI based systems triggers a: > > 'BUG: sleeping function called from invalid context' > > > > To prevent this bug, the cacheinfo is now allocated from the primary CPU > > when preemption and interrupts are enabled and before booting secondary > > CPUs. The cache levels/leaves are computed from DT/ACPI PPTT information > > only, without relying on any architecture specific mechanism if done so > > early. > > > > The other minor change included here is to handle shared caches at > > different levels when not all the CPUs on the system have the same > > cache hierarchy. > > While this gets rid of the "cacheinfo: Unable to detect cache hierarchy > for CPU N" warnings printed during boot, it resurrects the printing of > > Early cacheinfo failed, ret = -12 > > during early boot on all my RV64 platforms > > See also https://lore.kernel.org/all/CAMuHMdUBZ791fxCPkKQ6HCwLE4GJB2S35QC=SQ+X8w5Q4C_70g@mail.gmail.com/ > for a similar earlier version triggering the same issue. > > > ---------------------------------------------------------------- > > Pierre Gondois (6): > > arch_topology: Build cacheinfo from primary CPU > > Reverting commit 5944ce092b97caed ("arch_topology: Build cacheinfo > from primary CPU") fixes the issue. > OK, thanks for narrowing it to one patch. We will look at it. But does it work fine even with this errors ? We had seen such a behaviour in the past. It fails to initialise too early but works at later initcall level which I am not sure if we investigated why.
On Tue, Jan 24, 2023 at 02:42:45PM +0000, Sudeep Holla wrote: > On Tue, Jan 24, 2023 at 02:44:10PM +0100, Geert Uytterhoeven wrote: > > Hi Sudeep, > > > > On Fri, Jan 20, 2023 at 1:22 PM Sudeep Holla <sudeep.holla@arm.com> wrote: > > > It has been tested on RISC-V which is the main users outside of arm64. > > > > Has it? > > > > Hmm, I might have mixed up things then. I was on a vacation for quite some > time and might have assumed Conor response on the thread with testing. > Extremely sorry for that. However it was in -next for few days before > Greg applied to his tree. Sorry chief! The CI stuff we run on the RISC-V patchwork only provides build coverage etc & my CI against linux-next doesn't check for this kind of thing. I'll put it on my todo-list to add that, both for patchwork and in our internal CI. I only reviewed the patch that was moving the code to common group and not the others unfortunately. Next time I'll be sure to review the lot! Thanks, Conor.
On Tue, Jan 24, 2023 at 02:54:29PM +0000, Conor Dooley wrote: > On Tue, Jan 24, 2023 at 02:42:45PM +0000, Sudeep Holla wrote: > > On Tue, Jan 24, 2023 at 02:44:10PM +0100, Geert Uytterhoeven wrote: > > > Hi Sudeep, > > > > > > On Fri, Jan 20, 2023 at 1:22 PM Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > It has been tested on RISC-V which is the main users outside of arm64. > > > > > > Has it? > > > > > > > Hmm, I might have mixed up things then. I was on a vacation for quite some > > time and might have assumed Conor response on the thread with testing. > > Extremely sorry for that. However it was in -next for few days before > > Greg applied to his tree. > > Sorry chief! The CI stuff we run on the RISC-V patchwork only provides > build coverage etc & my CI against linux-next doesn't check for this kind > of thing. No worries, it was holiday hang over from my side. I did check and repond to the other thread during holiday and then mixed up things, my bad. Sorry for that. > I'll put it on my todo-list to add that, both for patchwork and in our > internal CI. Thanks. > I only reviewed the patch that was moving the code to common group and > not the others unfortunately. Next time I'll be sure to review the lot! > Also I really hope we don't have to change this much but who knows. I thought so few years back yet we are changing it so much in the recent days. Hope that will enter quiescent state soon ;) yet again. -- Regards, Sudeep