From: Dave Martin <Dave.Martin@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Oleg Nesterov <oleg@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org,
Doug Anderson <dianders@chromium.org>
Subject: Re: [RFC PATCH] arm64/sve,sme: Refine scalable regset sizes at boot
Date: Wed, 7 Feb 2024 12:32:48 +0000 [thread overview]
Message-ID: <ZcN4cGb66qjSId/B@e133380.arm.com> (raw)
In-Reply-To: <ZcNVyMyiFB3Nndth@finisterre.sirena.org.uk>
On Wed, Feb 07, 2024 at 10:04:56AM +0000, Mark Brown wrote:
> On Mon, Feb 05, 2024 at 05:27:20PM +0000, Dave Martin wrote:
>
> > index a5dc6f764195..5c2f91f84c31 100644
> > --- a/arch/arm64/kernel/fpsimd.c
> > +++ b/arch/arm64/kernel/fpsimd.c
> > @@ -1189,6 +1189,7 @@ void __init sve_setup(void)
> > pr_warn("%s: unvirtualisable vector lengths present\n",
> > info->name);
> >
> > + arch_ptrace_sve_init(sve_vq_from_vl(info->max_vl));
> > sve_efi_setup();
> > }
>
> This will only get run if the system actually supports SVE since the
> first thing that sve_setup() does is to exit if the system does not
> support SVE. That means that the size limiting will only be done on
> systems that have SVE, but since we unconditionally register all our
> regsets if the system doesn't have SVE it will end up with a maximally
> sized SVE regset registered which doesn't seem ideal. As I mentioned in
> the other thread we should probably just not be registering unsupported
> regsets with the core, that would avoid the issue without a change to
> this patch.
>
> A similar issue applies for SME.
Good point.
I guess if we're following this approach we also do have the option
to knock out entries of the array altogether once cpufeatures are
finalised.
If we want a quick fix the silly memory allocation triggering for
Douglas' splat then this probably isn't it, but if removing regsets at
boot time is desirable anyway, we might kill two birds with one stone
here.
I'll wait for progress on the other threads before digging too deeply
into this (but anyone wanting to see this patch expedited, please
shout!)
Cheers
---Dave
_______________________________________________
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: Dave Martin <Dave.Martin@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Oleg Nesterov <oleg@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org,
Doug Anderson <dianders@chromium.org>
Subject: Re: [RFC PATCH] arm64/sve,sme: Refine scalable regset sizes at boot
Date: Wed, 7 Feb 2024 12:32:48 +0000 [thread overview]
Message-ID: <ZcN4cGb66qjSId/B@e133380.arm.com> (raw)
In-Reply-To: <ZcNVyMyiFB3Nndth@finisterre.sirena.org.uk>
On Wed, Feb 07, 2024 at 10:04:56AM +0000, Mark Brown wrote:
> On Mon, Feb 05, 2024 at 05:27:20PM +0000, Dave Martin wrote:
>
> > index a5dc6f764195..5c2f91f84c31 100644
> > --- a/arch/arm64/kernel/fpsimd.c
> > +++ b/arch/arm64/kernel/fpsimd.c
> > @@ -1189,6 +1189,7 @@ void __init sve_setup(void)
> > pr_warn("%s: unvirtualisable vector lengths present\n",
> > info->name);
> >
> > + arch_ptrace_sve_init(sve_vq_from_vl(info->max_vl));
> > sve_efi_setup();
> > }
>
> This will only get run if the system actually supports SVE since the
> first thing that sve_setup() does is to exit if the system does not
> support SVE. That means that the size limiting will only be done on
> systems that have SVE, but since we unconditionally register all our
> regsets if the system doesn't have SVE it will end up with a maximally
> sized SVE regset registered which doesn't seem ideal. As I mentioned in
> the other thread we should probably just not be registering unsupported
> regsets with the core, that would avoid the issue without a change to
> this patch.
>
> A similar issue applies for SME.
Good point.
I guess if we're following this approach we also do have the option
to knock out entries of the array altogether once cpufeatures are
finalised.
If we want a quick fix the silly memory allocation triggering for
Douglas' splat then this probably isn't it, but if removing regsets at
boot time is desirable anyway, we might kill two birds with one stone
here.
I'll wait for progress on the other threads before digging too deeply
into this (but anyone wanting to see this patch expedited, please
shout!)
Cheers
---Dave
next prev parent reply other threads:[~2024-02-07 12:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 17:27 [RFC PATCH] arm64/sve,sme: Refine scalable regset sizes at boot Dave Martin
2024-02-05 17:27 ` Dave Martin
2024-02-06 11:07 ` Mark Brown
2024-02-06 11:07 ` Mark Brown
2024-02-07 12:25 ` Dave Martin
2024-02-07 12:25 ` Dave Martin
2024-02-07 10:04 ` Mark Brown
2024-02-07 10:04 ` Mark Brown
2024-02-07 12:32 ` Dave Martin [this message]
2024-02-07 12:32 ` Dave Martin
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=ZcN4cGb66qjSId/B@e133380.arm.com \
--to=dave.martin@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dianders@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--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.