mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Garg, Shivank" <shivankg@amd.com>
To: "david.laight.linux@gmail.com" <david.laight.linux@gmail.com>
Cc: "tejavojjala@google.com" <tejavojjala@google.com>,
	"Rao, Bharata Bhasker" <bharata@amd.com>,
	"rppt@kernel.org" <rppt@kernel.org>,
	"ankur.a.arora@oracle.com" <ankur.a.arora@oracle.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"vbabka@kernel.org" <vbabka@kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"david@kernel.org" <david@kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"surenb@google.com" <surenb@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"nhuhuan@google.com" <nhuhuan@google.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"tglx@kernel.org" <tglx@kernel.org>,
	"liam@infradead.org" <liam@infradead.org>,
	"Salunke, Hrushikesh" <Hrushikesh.Salunke@amd.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"mhocko@suse.com" <mhocko@suse.com>,
	"ljs@kernel.org" <ljs@kernel.org>,
	"rientjes@google.com" <rientjes@google.com>,
	"torvalds@linuxfoundation.org" <torvalds@linuxfoundation.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH RFC v2] mm: introduce copy_mc_highpages() and batch copy in folio_mc_copy()
Date: Mon, 19 Oct 2026 18:54:26 +0000	[thread overview]
Message-ID: <b22a59fa30183e13043e69ee91dfc77eca4d4a26.camel@amd.com> (raw)
In-Reply-To: <20261019131901.7a8fae90@pumpkin>

On Mon, 2026-10-19 at 13:19 +0100, David Laight wrote:
> On Mon, 19 Oct 2026 10:06:49 +0000
> Shivank Garg <shivankg@amd.com> wrote:
> 
> > folio_mc_copy() copies a folio one page at a time with copy_mc_highpage(),
> > so a 2MB folio makes 512 separate copy_mc_to_kernel() calls. Each page
> > pays the startup cost of the string instruction ("REP; MOVSB" on x86
> > CPUs with ERMS) plus a cond_resched().
> 
> Don't you always want to use 'rep movsq' for these aligned copies (on any
> cpu anyone cares about).
> I'm pretty even on some that don't advertise ERMS. 
> 
> The fastest a copy loop is ever going to run (on anything but the latest cpu)
> is one write every clock - so 8 bytes/clock.
> A 4k page will then take at least 512 clocks.
> Even an old sandy bridge cpu will (IIRC) copy 32 bytes/clock if the destination
> is 32 byte aligned (not much later cpu double that for 64byte aligned destinations).
> So the copy part takes at most 128 clocks.
> That makes 'rep movsq' faster unless the fixed overhead is in the P4 netburst
> range.
> (I was using lfence when I did my performance measurements, it hides
> the fixed latency of rep.)
> 
> I've never measured zen 1-4.
> 
> I also suspect the slow part of a 2M copy is all the D-cache misses
> (especially on the read side).
> 
> OTOH the longer copy is likely to be better...
> 

Thanks for taking a look and for the detailed explanation.

In my measurements, 'rep movsb' and 'rep movsq' perform about the
same for aligned, longer copies.

Since copy_mc_to_kernel() takes an arbitrary length, always using
'rep movsq' would mean adding an alignment/length, etc. or adding a
separate copy_mc_pages() (or something similar) for page-aligned copies.

I think that would be worthwhile x86 change on its own, independent of
this series. Here, I'm not changing the underlying copy mechanism and
behavior other callers.
 
Would it be okay to have hardware specific changes separately?


Thanks,
Shivank




  reply	other threads:[~2026-10-19 18:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 10:06 Shivank Garg
2026-10-19 11:09 ` Pedro Falcato
2026-10-19 12:23   ` David Hildenbrand (Arm)
2026-10-19 13:10     ` Garg, Shivank
2026-10-19 14:21       ` David Hildenbrand (Arm)
2026-10-19 17:32         ` Garg, Shivank
2026-10-19 13:16   ` Garg, Shivank
2026-10-19 12:19 ` David Laight
2026-10-19 18:54   ` Garg, Shivank [this message]
2026-10-19 20:52     ` David Laight

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=b22a59fa30183e13043e69ee91dfc77eca4d4a26.camel@amd.com \
    --to=shivankg@amd.com \
    --cc=Hrushikesh.Salunke@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=ankur.a.arora@oracle.com \
    --cc=bharata@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.laight.linux@gmail.com \
    --cc=david@kernel.org \
    --cc=hpa@zytor.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=nhuhuan@google.com \
    --cc=rientjes@google.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=tejavojjala@google.com \
    --cc=tglx@kernel.org \
    --cc=torvalds@linuxfoundation.org \
    --cc=vbabka@kernel.org \
    --cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®