为何copy_user_enhanced_fast_string在AVX可用时未采用vmovaps/vmovups？

Great question! Let's unpack this by first looking at the x86 implementation you shared, then diving into the reasons behind avoiding AVX, and finally addressing whether AVX has no performance value for memory copies.

First, here's the assembly code for context:

ENTRY(copy_user_enhanced_fast_string)
ASM_STAC
cmpl $64,%edx
jb .L_copy_short_string /* less then 64 bytes, avoid the costly 'rep' */
movl %edx,%ecx
1: rep movsb
xorl %eax,%eax
ASM_CLAC
ret
.section .fixup,"ax"
12: movl %ecx,%edx /* ecx is zerorest also */
jmp .Lcopy_user_handle_tail
.previous
_ASM_EXTABLE_UA(1b, 12b)
ENDPROC(copy_user_enhanced_fast_string)

Key Reasons for Avoiding AVX Instructions #

1. Backward Compatibility is Non-Negotiable #

The Linux kernel is built to run on every x86 CPU still in active use, including older systems that don't support AVX (pre-2011 Intel Sandy Bridge, pre-2011 AMD Bulldozer). Using AVX instructions would immediately break compatibility with these machines—a hard no for the kernel's philosophy of broad hardware support.

Even on AVX-capable CPUs, switching between SSE and AVX instruction modes incurs a hidden performance penalty (the "AVX-SSE transition penalty"). Since this copy function is a hot path in I/O-bound workloads, adding such a penalty could easily wipe out any potential gains from AVX.

2. rep movsb is Extremely Optimized on Modern CPUs #

Don't let the simple syntax fool you—modern x86 CPUs (Intel Fast String, AMD Enhanced MOVSB) have turned rep movsb into a highly adaptive, hardware-accelerated instruction. Under the hood:

• It detects copy size, memory alignment, and memory type (cached vs. uncached) automatically
• It leverages the most efficient internal implementation for the scenario, which may even use vector operations like AVX without exposing them in kernel code
• For variable-length or misaligned copies (common in user-kernel interactions), it often outperforms hand-written AVX loops because the CPU can optimize on the fly

The function's name even hints at this: copy_user_enhanced_fast_string explicitly relies on the CPU's Fast String capabilities.

3. User-Space Memory Copy Adds Unique Complexity #

Copying between kernel and user space isn't just a simple memory transfer—user memory can be unaligned, paged out, or invalid (triggering page faults or access errors). Using AVX instructions would require:

• Extra alignment checks (since vmovaps requires aligned memory, while vmovups has overhead for unaligned access)
• More complex fault recovery logic, extending the kernel's fixup mechanism (_ASM_EXTABLE_UA in the code) to handle AVX-specific state

This added complexity isn't justified when rep movsb already handles all these cases cleanly and efficiently.

Does AVX Offer No Performance Advantage in Copy Scenarios? #

Short answer: No, but it's not a universal win.

• In controlled, ideal scenarios (large, perfectly aligned copies on AVX-native hardware), hand-written AVX loops can outperform rep movsb. But these cases are rare in real-world user-kernel interactions, where copy sizes and alignment vary widely.
• The kernel prioritizes consistent performance across all workloads and hardware. rep movsb adapts to the CPU and copy parameters automatically, so it delivers reliable performance without requiring per-hardware optimizations.
• Benchmarks often show rep movsb matching or exceeding AVX copy performance in real-world use, especially when accounting for the overhead of AVX-SSE transitions, alignment checks, and fault handling.

In short, the kernel uses rep movsb not because AVX is useless for copying, but because it's the most robust, compatible, and consistently performant choice for this critical hot path.

内容的提问来源于stack exchange，提问作者St.Antario