From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 86AB53858C5F; Wed, 21 Jun 2023 03:00:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 86AB53858C5F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687316407; bh=FRRJTfBqNMlLLTs2hSor9yswiJ9o8H2C5v0RGF9GJz4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ttwrMW76KGFU0I2dMe/L5lXlBVfi6E6xm5XQqPrRhodlnEoqCHPpHfz1uQBS97DJz IPaSwNjXhwWdjszEOE+ugDnvQtUdnFnDccyHaExkfzszUodwCBdP4VWXzKitvdRzgu tPSs+nfd0xk3OiBDwo3/rWtSNe7m51NPSqTXS5PI= From: "andres at anarazel dot de" To: glibc-bugs@sourceware.org Subject: [Bug nptl/29029] poll() spuriously returns EINTR during thread cancellation and with cancellation disabled Date: Wed, 21 Jun 2023 03:00:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.34 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: andres at anarazel dot de X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org X-Bugzilla-Target-Milestone: 2.36 X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29029 Andres Freund changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andres at anarazel dot de --- Comment #9 from Andres Freund --- 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) G= old 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 pi= nned 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.=20=20 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 is= sue. Do you want me to create a new issue or leave it just here? --=20 You are receiving this mail because: You are on the CC list for the bug.=