Re: [PATCH v5 7/8] x86/string: extend memcpy_flushcache() fixed-size fastpaths

On Fri, 3 Jul 2026 12:56:19 -0700, [email protected] wrote:

> On Thu, Jul 02, 2026 at 03:37:50PM +0800, Li Zhe wrote:
> > The relevant target sizes here are the x86_64 sizeof(struct page)
> > values which patch 8 can hit: 64, 80, and 96 bytes.
> >
> > On x86_64, CONFIG_HAVE_ALIGNED_STRUCT_PAGE keeps struct page 16-byte
> > aligned. That gives 64 bytes in the common case, 80 bytes when
> > WANT_PAGE_VIRTUAL or CONFIG_KMSAN adds extra fields, and 96 bytes when
> > both are present. I stopped there deliberately because this series does
> > not have a current caller which needs larger constant sizes.
> >
> > The 32-byte and 48-byte cases were added only as intermediate fixed-size
> > combinations used to build those larger struct page-sized copies while
> > keeping them on the inline movnti path.
> 
> This needs to be in a comment over that code so that it is clear why that
> distinction has been made.

Thanks. I will add a code comment for that in v6.

> > Yes. The separate helper is there exactly because the added
> > 32/48/64/80/96-byte cases carry an extra 8-byte destination-alignment
> > check, while I left the existing 4/8/16-byte inline cases unchanged.
> >
> > The intent was to keep the larger fixed-size cases on the inline
> > movnti path only when they already match the alignment assumptions
> > used by __memcpy_flushcache(); otherwise they fall back to that
> > out-of-line helper, which already handles the misaligned head/tail
> > fragments before entering its movnti loops.
> 
> Why can't the larger MOVNTI sizes deal with misaligned cases too and thus make
> the code even simpler and more straight-forward this way?

The extra IS_ALIGNED() check is meant as a conservative performance
choice, not because MOVNTI itself would be invalid on a misaligned
destination.

As the Intel optimization reference manual notes, higher-throughput
data movement usually comes with alignment considerations, and can
be more efficient when the destination is naturally aligned.

So for these larger fixed-size cases, I kept the inline path limited
to the aligned case. For misaligned destinations, falling back to
__memcpy_flushcache() is expected to be the better choice, since it
already handles the unaligned head first and only then enters its
MOVNTI loops.

I will make that rationale explicit in the code comment and commit
message in v6.

Thanks,
Zhe