Re: [PATCH v2] mm: Optimized hugepage zeroing & copying from user

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 21, 2020 at 03:48:04PM +0200, Vlastimil Babka wrote:
> On 4/21/20 3:39 PM, Will Deacon wrote:
> > On Tue, Apr 21, 2020 at 02:48:04PM +0200, Vlastimil Babka wrote:
> >> On 4/21/20 2:47 PM, Vlastimil Babka wrote:
> >> > 
> >> > It was suspected that current Intel can prefetch forward and backwards, and the
> >> > tested ARM64 microarchitecture only backwards, can it be true? The current code
> >> 
> >> Oops, tested ARM64 microarchitecture I meant "only forwards".
> > 
> > I'd be surprised if that's the case, but it could be that there's an erratum
> > workaround in play which hampers the prefetch behaviour. We generally try
> > not to assume too much about the prefetcher on arm64 because they're not
> > well documented and vary wildly between different micro-architectures.
> 
> Yeah it's probably not as simple as I thought, as the test code [1] shows the
> page iteration goes backwards, but per-page memsets are not special. So maybe
> it's not hardware specifics, but x86 memtest implementation is also done
> backwards, so it fits the backwards outer loop, but arm64 memset is forward, so
> the resulting pattern is non-linear?

A straightforward linear prefetcher would probably be defeated by that sort
of thing, yes, but I'd have thought that the recent CPUs (e.g. A76 which I
think is the "big" CPU in the SoC mentioned at the start of the thread)
would still have a fighting chance at prefetching based on non-linear
histories.

However, to my earlier point, we're making this more difficult than it needs
to be for the hardware and we shouldn't assume that all prefetchers will
handle it gracefully, so keeping the core code relatively straightforward
does seem to be the best bet. Alarm bells just rang initially when it
appeared that we were optimising code under arch/arm64 rather than improving
the core code, but I now have a better picture of what's going on (thanks).

Alternatively, we could switch our memset() around, but I'm worried that
we could end up hurting something else by doing that. I guess we could add a
memset_backwards() version if we *had* to...

> In that case it's also a question if the measurement was done in kernel or
> userspace, and if userspace memset have any implications for kernel memset...

Sounds like it was done in userspace. If I get a chance later on, I'll try
to give it a spin here on some of the boards I have kicking around.

Will




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux