Re: Monday Patch Queue Review update (2023-11-06)

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 06/11/23 18:46, Noah Goldstein wrote:
> On Mon, Nov 6, 2023 at 3:24 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 06/11/23 15:18, Noah Goldstein wrote:
>>> On Mon, Nov 6, 2023 at 8:42 AM Carlos O'Donell <carlos@redhat.com> wrote:
>>>>
>>>> Most recent meeting status is always here:
>>>> https://sourceware.org/glibc/wiki/PatchworkReviewMeetings#Update
>>>>
>>>> Meeting: 2023-11-06 @ 0900h EST5EDT
>>>>
>>>> Video/Audio: https://bbb.linuxfoundation.org/room/adm-alk-1uu-7fu
>>>>
>>>> IRC: #glibc on OFTC.
>>>>
>>>> Review new patches and restart review at the top.
>>>>
>>>>  * State NEW delegate NOBODY at 459 patches.
>>>>  * Carlos's SLI at 214 days average patch age in queue and 103254 accumulated patch days.
>>>>  * Starting at 79195.
>>>>  * v2: Multiple floating-point environment fixes (Adhemerval)
>>>>   * Carlos to look at the hppa code.
>>>>  * Update BAD_TYPECHECK to work on x86_64 (Flavio)
>>>>   * Needs Hurd review.
>>>>  * Remove ia64-linux-gnu (Adhemerval)
>>>>   * On thread discussion that upstream kernel support needed for a Linux port.
>>>>  * [1/6] aarch64: Add vector implementations of asin routines (Joe)
>>>>   * Szabolcs: More vector math functions.
>>>>  * x86: Only align destination to 1x VEC_SIZE in memset 4x loop (Noah)
>>>>  * x86: Fix unchecked AVX512-VBMI2 usage in strrchr-evex-base.S (Noah)
>>>>  * v3: Add a tunable to decorate anonymous memory maps (Adhemerval)
>>>>   * Missing 3 RBs for v3.
>>>>  * x86: Improve ERMS usage on Zen3+ (Adhemerval)
>>>>   * Would be valuable to reach out to AMD for feedback.
>>>
>>> Missed the meeting, but is there a bit more context to this?
>>
>> I wrote the patchset summary with my finding on a Zen3 core [1], but
>> essentially what I have found is ERMS is not really an advantage on
>> the sizes where it is being enabled for Zen3+ cores (between 2113,
>> rep_movsb_threshold, and L2 cache size, rep_movsb_stop_threshold or
>> 524288 on a Zen3 core).
>>
>> The provided microbenchmark provided by BZ#30995 shows that some
>> alignments the resulting throughput is *really* bad; while for others
>> is still slight worse than vectorized alternative.  So the patchset
>> just disables ERMS for Zen3+ cores, and I really seem even a small
>> improvement on SPECcpu20017 502.gcc_r  (which hits really hard memset).
>>
> 
> The BZ seem to be memcpy only, is this param being exported to memset
> as well? If so we probably need to NT-store memset impl.

We have x86_rep_stosb_threshold for memset and I have extended the memset
comment to state how it is used [1].

[1] https://patchwork.sourceware.org/project/glibc/patch/20231031200925.3297456-5-adhemerval.zanella@linaro.org/