From: Phil Auld <pauld@redhat.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arch/arm64: Fix topology initialization for core scheduling
Date: Wed, 30 Mar 2022 11:52:49 -0400 [thread overview]
Message-ID: <YkR80Wp+wWatdYa6@lorien.usersys.redhat.com> (raw)
In-Reply-To: <5dc3a40e-f071-3ac8-4bf0-f555b9d94ff1@arm.com>
On Wed, Mar 30, 2022 at 05:48:34PM +0200 Dietmar Eggemann wrote:
> On 29/03/2022 21:50, Phil Auld wrote:
> > On Tue, Mar 29, 2022 at 08:55:08PM +0200 Dietmar Eggemann wrote:
> >> On 29/03/2022 17:20, Phil Auld wrote:
> >>> On Tue, Mar 29, 2022 at 04:02:22PM +0200 Dietmar Eggemann wrote:
> >>>> On 22/03/2022 17:03, Phil Auld wrote:
>
> [...]
>
> >>> This instance is an HPE Apollo 70 set to smt-4. I believe it's ThunderX2
> >>> chips.
> >>>
> >>> ARM (CN9980-2200LG4077-Y21-G)
> >> I'm using the same processor just with ACPI/PPTT.
> >>
> >
> > Maybe I'm misinformed about these systems having no PPTT...
> >
> > I'm reclaiming the system. Is there a way I can tell from userspace?
>
> # cat /sys/firmware/acpi/tables/PPTT > pptt.dat
> # iasl -d pptt.dat
> # vim pptt.dsl
>
Thanks, I'll git that a try. I suspect these are the same as yours though
and I was just mistaken :)
> [...]
>
> >> so no SMT sched domain. The MPIDR-based topology fallback code in
> >> store_cpu_topology() forces `cpuid_topo->thread_id = -1`.
> >
> > Right. So since I'm getting SMT it must not have package_id == -1.
> > In which case you should be able to reproduce it because it must
> > be that the call the update_siblings_masks() is required. That
> > appears to only be called from store_cpu_topology() which is
> > after the scheduler has already setup the core pointers.
> >
> > The fix could be the same but I should reword the commit message
> > since it should effect all SMT arm systems I'd think.
> >
> > Or maybe the ACPI topology code should call update_sibling_masks().
> >>
> >> IMHO this is why on my machine I don't see this issue while running:
> >>
> >> root@oss-apollo7007:~# stress-ng --prctl 256 -t 60
> >> stress-ng: info: [2388042] dispatching hogs: 256 prctl
> >>
> >> Is there something I miss in my setup to provoke this issue?
> >>
> >
> > Make sure you have a stress-ng that is new enough and built against
> > headers that have the CORE_SCHED prctls defined.
>
> Ah, I was using a pretty old version 0.11.07. Now I switched to 0.13.12
> which includes:
>
> 9038e442b92d - stress-prctl: add Linux 5.14 PR_SCHED_CORE prctl
>
> To get SCHED_CORE activated in stress-prctl.c, as a quick hack, I had to
> add the definitions of PR_SCHED_CORE, PR_SCHED_CORE_GET, etc. to this file.
>
> Now the issue you described triggers on this machine immediately.
>
Great! I'll repost the patch with a more accurate commit message then.
And if you come up with something different that works for me too. Let
me know and I'll test it here.
Cheers,
Phil
--
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Phil Auld <pauld@redhat.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arch/arm64: Fix topology initialization for core scheduling
Date: Wed, 30 Mar 2022 11:52:49 -0400 [thread overview]
Message-ID: <YkR80Wp+wWatdYa6@lorien.usersys.redhat.com> (raw)
In-Reply-To: <5dc3a40e-f071-3ac8-4bf0-f555b9d94ff1@arm.com>
On Wed, Mar 30, 2022 at 05:48:34PM +0200 Dietmar Eggemann wrote:
> On 29/03/2022 21:50, Phil Auld wrote:
> > On Tue, Mar 29, 2022 at 08:55:08PM +0200 Dietmar Eggemann wrote:
> >> On 29/03/2022 17:20, Phil Auld wrote:
> >>> On Tue, Mar 29, 2022 at 04:02:22PM +0200 Dietmar Eggemann wrote:
> >>>> On 22/03/2022 17:03, Phil Auld wrote:
>
> [...]
>
> >>> This instance is an HPE Apollo 70 set to smt-4. I believe it's ThunderX2
> >>> chips.
> >>>
> >>> ARM (CN9980-2200LG4077-Y21-G)
> >> I'm using the same processor just with ACPI/PPTT.
> >>
> >
> > Maybe I'm misinformed about these systems having no PPTT...
> >
> > I'm reclaiming the system. Is there a way I can tell from userspace?
>
> # cat /sys/firmware/acpi/tables/PPTT > pptt.dat
> # iasl -d pptt.dat
> # vim pptt.dsl
>
Thanks, I'll git that a try. I suspect these are the same as yours though
and I was just mistaken :)
> [...]
>
> >> so no SMT sched domain. The MPIDR-based topology fallback code in
> >> store_cpu_topology() forces `cpuid_topo->thread_id = -1`.
> >
> > Right. So since I'm getting SMT it must not have package_id == -1.
> > In which case you should be able to reproduce it because it must
> > be that the call the update_siblings_masks() is required. That
> > appears to only be called from store_cpu_topology() which is
> > after the scheduler has already setup the core pointers.
> >
> > The fix could be the same but I should reword the commit message
> > since it should effect all SMT arm systems I'd think.
> >
> > Or maybe the ACPI topology code should call update_sibling_masks().
> >>
> >> IMHO this is why on my machine I don't see this issue while running:
> >>
> >> root@oss-apollo7007:~# stress-ng --prctl 256 -t 60
> >> stress-ng: info: [2388042] dispatching hogs: 256 prctl
> >>
> >> Is there something I miss in my setup to provoke this issue?
> >>
> >
> > Make sure you have a stress-ng that is new enough and built against
> > headers that have the CORE_SCHED prctls defined.
>
> Ah, I was using a pretty old version 0.11.07. Now I switched to 0.13.12
> which includes:
>
> 9038e442b92d - stress-prctl: add Linux 5.14 PR_SCHED_CORE prctl
>
> To get SCHED_CORE activated in stress-prctl.c, as a quick hack, I had to
> add the definitions of PR_SCHED_CORE, PR_SCHED_CORE_GET, etc. to this file.
>
> Now the issue you described triggers on this machine immediately.
>
Great! I'll repost the patch with a more accurate commit message then.
And if you come up with something different that works for me too. Let
me know and I'll test it here.
Cheers,
Phil
--
next prev parent reply other threads:[~2022-03-30 16:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-22 16:03 [PATCH] arch/arm64: Fix topology initialization for core scheduling Phil Auld
2022-03-22 16:03 ` Phil Auld
2022-03-29 14:02 ` Dietmar Eggemann
2022-03-29 14:02 ` Dietmar Eggemann
2022-03-29 15:20 ` Phil Auld
2022-03-29 15:20 ` Phil Auld
2022-03-29 18:55 ` Dietmar Eggemann
2022-03-29 18:55 ` Dietmar Eggemann
2022-03-29 19:50 ` Phil Auld
2022-03-29 19:50 ` Phil Auld
2022-03-30 15:48 ` Dietmar Eggemann
2022-03-30 15:48 ` Dietmar Eggemann
2022-03-30 15:52 ` Phil Auld [this message]
2022-03-30 15:52 ` Phil Auld
2022-03-30 16:07 ` Phil Auld
2022-03-30 16:07 ` Phil Auld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YkR80Wp+wWatdYa6@lorien.usersys.redhat.com \
--to=pauld@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.