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
