mbox series

[GIT,PULL] cacheinfo/arch_topology: Updates for v6.3

Message ID 20230120121856.1407369-1-sudeep.holla@arm.com (mailing list archive)
State New, archived
Headers show
Series [GIT,PULL] cacheinfo/arch_topology: Updates for v6.3 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/archtopo-cacheinfo-updates-6.3

Message

Sudeep Holla Jan. 20, 2023, 12:18 p.m. UTC
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

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.

----------------------------------------------------------------
Pierre Gondois (6):
      cacheinfo: Use RISC-V's init_cache_level() as generic OF implementation
      cacheinfo: Return error code in init_of_cache_level()
      cacheinfo: Check 'cache-unified' property to count cache leaves
      ACPI: PPTT: Remove acpi_find_cache_levels()
      ACPI: PPTT: Update acpi_find_last_cache_level() to acpi_get_cache_info()
      arch_topology: Build cacheinfo from primary CPU

Yong-Xuan Wang (1):
      cacheinfo: Fix shared_cpu_map to handle shared caches at different levels

 arch/arm64/kernel/cacheinfo.c |  11 +--
 arch/riscv/kernel/cacheinfo.c |  42 -----------
 drivers/acpi/pptt.c           |  93 ++++++++++++++----------
 drivers/base/arch_topology.c  |  12 +++-
 drivers/base/cacheinfo.c      | 161 +++++++++++++++++++++++++++++++++++-------
 include/linux/cacheinfo.h     |  11 ++-
 6 files changed, 213 insertions(+), 117 deletions(-)

Comments

Greg KH Jan. 20, 2023, 12:41 p.m. UTC | #1
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
Geert Uytterhoeven Jan. 24, 2023, 1:44 p.m. UTC | #2
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
Sudeep Holla Jan. 24, 2023, 2:42 p.m. UTC | #3
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.
Conor Dooley Jan. 24, 2023, 2:54 p.m. UTC | #4
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.
Sudeep Holla Jan. 24, 2023, 3:11 p.m. UTC | #5
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