[Bug nptl/29029] poll() spuriously returns EINTR during thread cancellation and with cancellation disabled

["andres at anarazel dot de" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29029

Andres Freund <andres at anarazel dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andres at anarazel dot de

--- Comment #9 from Andres Freund <andres at anarazel dot de> ---
FWIW, the fix / revert (404656009b) seems to have lead to a noticeable
performance regression.

Comparing a process and a single thread doing 10M, on a "Intel(R) Xeon(R) Gold
5215 CPU @ 2.50GHz", I measured:
1) pread()s of 4096 bytes of data
2) close(-1)

glibc commit 404656009b:
testing without threads, performing 10000000 syscalls
        pread() via libc: 3035.157 ms
        pread() via syscall(): 3048.916 ms
        close(-1) via libc: 993.145 ms
        close(-1) via syscall(): 993.274 ms
testing with 1 threads, performing 10000000 syscalls each
        pread() via libc: 3400.858 ms
        pread() via syscall(): 3135.069 ms
        close(-1) via libc: 1203.851 ms
        close(-1) via syscall(): 996.809 ms

glibc commit 2376944b9e:
testing without threads, performing 10000000 syscalls
        pread() via libc: 3048.536 ms
        pread() via syscall(): 3049.653 ms
        close(-1) via libc: 968.820 ms
        close(-1) via syscall(): 950.485 ms
testing with 1 threads, performing 10000000 syscalls each
        pread() via libc: 3203.544 ms
        pread() via syscall(): 3142.467 ms
        close(-1) via libc: 1020.983 ms
        close(-1) via syscall(): 953.038 ms

To reduce variability this was run with turbo mode disabled and the test pinned
to an otherwise unused core and were run against both glibc in sequence,
without a reboot inbetween, with a few repetitions.

Looking at a profile it's obvious that the difference primarily is from
__GI___pthread_disable_asynccancel() and __GI___pthread_enable_asynccancel().
There's also some difference in kernel overhead, but that obviously applies to
both glibc versions.

It's one thing for something as pointless as close(-1) to regress ~18%, but the
fact that this also regresses workloads doing useful, non-trivial syscalls,
like pread() by ~5% seems worrisome.  

I have been seeing __GI___pthread_disable_asynccancel etc in more an more
production profiles for a while and finally spent the time analyzing the issue.


Do you want me to create a new issue or leave it just here?

-- 
You are receiving this mail because:
You are on the CC list for the bug.