linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Prathu Baronia <prathu.baronia@oneplus.com>,
	catalin.marinas@arm.com, alexander.duyck@gmail.com,
	chintan.pandya@oneplus.com, mhocko@suse.com,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	gregkh@linuxfoundation.com, gthelen@google.com, jack@suse.cz,
	ken.lin@oneplus.com, gasine.xu@oneplus.com, ying.huang@intel.com,
	mark.rutland@arm.com
Subject: Re: [PATCH v2] mm: Optimized hugepage zeroing & copying from user
Date: Wed, 22 Apr 2020 09:18:53 +0100	[thread overview]
Message-ID: <20200422081852.GB29541@willie-the-truck> (raw)
In-Reply-To: <5e334947-22e9-e59d-f7bb-63e04cc8caf0@suse.cz>

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


  parent reply	other threads:[~2020-04-22  8:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14 15:38 Prathu Baronia
2020-04-14 17:03 ` Michal Hocko
2020-04-14 17:41   ` Daniel Jordan
     [not found]   ` <20200414184743.GB2097@oneplus.com>
2020-04-14 19:32     ` Alexander Duyck
2020-04-15  3:40       ` Huang, Ying
2020-04-15 11:09         ` Michal Hocko
2020-04-19 12:05       ` Prathu Baronia
2020-04-14 19:40     ` Michal Hocko
2020-04-15  3:27 ` Huang, Ying
2020-04-16  1:21   ` Huang, Ying
2020-04-19 15:58   ` Prathu Baronia
2020-04-20  0:18     ` Huang, Ying
2020-04-21  9:36       ` Prathu Baronia
2020-04-21 10:09         ` Will Deacon
2020-04-21 12:47           ` Vlastimil Babka
2020-04-21 12:48             ` Vlastimil Babka
2020-04-21 13:39               ` Will Deacon
2020-04-21 13:48                 ` Vlastimil Babka
2020-04-21 13:56                   ` Chintan Pandya
2020-04-22  8:18                   ` Will Deacon [this message]
2020-04-22 11:19                     ` Will Deacon
2020-04-22 14:38                       ` Prathu Baronia
2020-05-01  8:58                         ` Prathu Baronia
2020-05-05  8:59                           ` Will Deacon
2020-04-21 13:00             ` Michal Hocko
2020-04-21 13:10               ` Will Deacon
2020-04-17  7:48 ` [mm] 134c8b410f: vm-scalability.median -7.9% regression kernel test robot

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=20200422081852.GB29541@willie-the-truck \
    --to=will@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.duyck@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=chintan.pandya@oneplus.com \
    --cc=gasine.xu@oneplus.com \
    --cc=gregkh@linuxfoundation.com \
    --cc=gthelen@google.com \
    --cc=jack@suse.cz \
    --cc=ken.lin@oneplus.com \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=mhocko@suse.com \
    --cc=prathu.baronia@oneplus.com \
    --cc=vbabka@suse.cz \
    --cc=ying.huang@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox