Re: [PATCH v3 1/4] x86/clear_page: extend clear_page*() for multi-page clearing

[Mateusz Guzik <mjguzik@gmail.com>]

On Tue, Apr 15, 2025 at 8:14 AM Ankur Arora <ankur.a.arora@oracle.com> wrote:
>
>
> Mateusz Guzik <mjguzik@gmail.com> writes:
> > With that sucker out of the way, an optional quest is to figure out if
> > rep stosq vs rep stosb makes any difference for pages -- for all I know
> > rep stosq is the way. This would require testing on quite a few uarchs
> > and I'm not going to blame anyone for not being interested.
>
> IIRC some recent AMD models (Rome?) did expose REP_GOOD but not ERMS.
>

The uarch does not have it or the bit magically fails to show up?
Worst case, should rep stosb be faster on that uarch, the kernel can
pretend the bit is set.

> > Let's say nobody bothered OR rep stosb provides a win. In that case this
> > can trivially ALTERNATIVE between rep stosb and rep stosq based on ERMS,
> > no func calls necessary.
>
> We shouldn't need any function calls for ERMS and REP_GOOD.
>
> I think something like this untested code should work:
>
>         asm volatile(
>             ALTERNATIVE_2("call clear_pages_orig",
>                           "rep stosb", X86_FEATURE_REP_GOOD,
>                           "shrl $3,%ecx; rep stosq", X86_FEATURE_ERMS,
>                           : "+c" (size), "+D" (addr), ASM_CALL_CONSTRAINT
>                           : "a" (0)))
>

That's what I'm suggesting, with one difference: whack
clear_pages_orig altogether.

-- 
Mateusz Guzik <mjguzik gmail.com>