[PATCH v3 0/8] arm64/sve: First steps towards optimizing syscalls

zhang.lei at fujitsu.com zhang.lei at fujitsu.com
Mon Jul 20 22:43:47 EDT 2020


On linux-5.8.0-rc5, I have tested the v3 patch.
All the test is passed.
Please add 
Tested-by: Zhang Lei <address at hidden>

Best Regards,
Lei Zhang

> From: Dave Martin <Dave.Martin at arm.com>
> Sent: Monday, July 20, 2020 7:45 PM
> To: Mark Brown <broonie at kernel.org>
> Cc: Julien Grall <julien at xen.org>; Catalin Marinas
> <catalin.marinas at arm.com>; Zhang, Lei/張 雷 <zhang.lei at fujitsu.com>; Will
> Deacon <will at kernel.org>; linux-arm-kernel at lists.infradead.org; Daniel Kiss
> <Daniel.Kiss at arm.com>
> Subject: Re: [PATCH v3 0/8] arm64/sve: First steps towards optimizing syscalls
> 
> On Wed, Jul 15, 2020 at 06:11:16PM +0100, Mark Brown wrote:
> > On Wed, Jul 15, 2020 at 05:49:34PM +0100, Dave Martin wrote:
> >
> > > I wonder whether we ought to accompany this with a crude mechanism
> > > to choose dynamically between setting TIF_SVE_NEEDS_FLUSH and
> > > keeping the old behaviour.
> >
> > > My concern with doing this unconditionally has been that we can end
> > > up with TIF_SVE permanently stuck on, which increases the per-task
> overhead.
> > > This is not a worry if the user task really does use SVE once per
> > > context switch, but not so good if, say, the libc startup probes for
> > > SVE to initialise some internal logic but the task otherwise doesn't
> > > use it.  (This is just a worry: I haven't looked for evidence to
> > > support
> > > it.)
> >
> > Yes, it's a concern.  My thought was to follow this up with something
> > which copies what some of the other architectures are doing for FP
> > registers and go back to the existing behaviour after a certain number
> > of syscalls.  That has a bunch of room for debate and bikeshedding
> > about what exactly an appropriate number might be of course.
> 
> Ack, that sounds like a fair approach.
> 
> Of course, we could try to implement some kind of clever backoff but it's
> probably not worth it for now.
> 
> Cheers
> ---Dave



More information about the linux-arm-kernel mailing list