public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug nptl/16410] New: pthread_cond_timedwait has 70us latency when abstime already expired @ 2014-01-08 1:43 weiqi at kylinos dot com.cn 2014-01-08 1:49 ` [Bug nptl/16410] " weiqi at kylinos dot com.cn ` (3 more replies) 0 siblings, 4 replies; 5+ messages in thread From: weiqi at kylinos dot com.cn @ 2014-01-08 1:43 UTC (permalink / raw) To: glibc-bugs https://sourceware.org/bugzilla/show_bug.cgi?id=16410 Bug ID: 16410 Summary: pthread_cond_timedwait has 70us latency when abstime already expired Product: glibc Version: 2.18 Status: NEW Severity: normal Priority: P2 Component: nptl Assignee: unassigned at sourceware dot org Reporter: weiqi at kylinos dot com.cn CC: drepper.fsp at gmail dot com Created attachment 7340 --> https://sourceware.org/bugzilla/attachment.cgi?id=7340&action=edit the test.c for this problem Since this patch (http://repo.or.cz/w/glibc.git/commit/e88726b483a275824e852f64476087568dbae7bb), it seems that pthread_cond_timedwait.S does not care the arg "abstime" which may already expired. Pass it to syscall futex, if the futex have the ability FUTEX_CLOCK_REALTIME. Before the futex_clock_realtime patch, pthread_cond_timedwait.S check the abstime arg firstly by syscall clock_gettime, so if abstime already expired, pthread_cond_timedwait would return -ETIMEDOUT immediatly. I have reported a bug to redhat bugzilla described this case(https://bugzilla.redhat.com/show_bug.cgi?id=1048731),and added a test.c show this. The kernel futex_wait use hrtimer to calculate timeout, and do not special considerations such cases. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug nptl/16410] pthread_cond_timedwait has 70us latency when abstime already expired 2014-01-08 1:43 [Bug nptl/16410] New: pthread_cond_timedwait has 70us latency when abstime already expired weiqi at kylinos dot com.cn @ 2014-01-08 1:49 ` weiqi at kylinos dot com.cn 2014-01-11 12:58 ` neleai at seznam dot cz ` (2 subsequent siblings) 3 siblings, 0 replies; 5+ messages in thread From: weiqi at kylinos dot com.cn @ 2014-01-08 1:49 UTC (permalink / raw) To: glibc-bugs https://sourceware.org/bugzilla/show_bug.cgi?id=16410 weiqi <weiqi at kylinos dot com.cn> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |weiqi at kylinos dot com.cn -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug nptl/16410] pthread_cond_timedwait has 70us latency when abstime already expired 2014-01-08 1:43 [Bug nptl/16410] New: pthread_cond_timedwait has 70us latency when abstime already expired weiqi at kylinos dot com.cn 2014-01-08 1:49 ` [Bug nptl/16410] " weiqi at kylinos dot com.cn @ 2014-01-11 12:58 ` neleai at seznam dot cz 2014-01-13 2:36 ` weiqi at kylinos dot com.cn 2014-06-13 9:10 ` fweimer at redhat dot com 3 siblings, 0 replies; 5+ messages in thread From: neleai at seznam dot cz @ 2014-01-11 12:58 UTC (permalink / raw) To: glibc-bugs https://sourceware.org/bugzilla/show_bug.cgi?id=16410 Ondrej Bilka <neleai at seznam dot cz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |neleai at seznam dot cz Version|2.18 |2.20 --- Comment #1 from Ondrej Bilka <neleai at seznam dot cz> --- This could be handled after freeze. It looks that patch would be putting a check back which should be relatively straightforward. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug nptl/16410] pthread_cond_timedwait has 70us latency when abstime already expired 2014-01-08 1:43 [Bug nptl/16410] New: pthread_cond_timedwait has 70us latency when abstime already expired weiqi at kylinos dot com.cn 2014-01-08 1:49 ` [Bug nptl/16410] " weiqi at kylinos dot com.cn 2014-01-11 12:58 ` neleai at seznam dot cz @ 2014-01-13 2:36 ` weiqi at kylinos dot com.cn 2014-06-13 9:10 ` fweimer at redhat dot com 3 siblings, 0 replies; 5+ messages in thread From: weiqi at kylinos dot com.cn @ 2014-01-13 2:36 UTC (permalink / raw) To: glibc-bugs https://sourceware.org/bugzilla/show_bug.cgi?id=16410 --- Comment #2 from weiqi <weiqi at kylinos dot com.cn> --- (In reply to Ondrej Bilka from comment #1) > This could be handled after freeze. > Is there any reason futex_wait do not check the abstime at first? > > It looks that patch would be putting a check back which should be relatively > straightforward. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug nptl/16410] pthread_cond_timedwait has 70us latency when abstime already expired 2014-01-08 1:43 [Bug nptl/16410] New: pthread_cond_timedwait has 70us latency when abstime already expired weiqi at kylinos dot com.cn ` (2 preceding siblings ...) 2014-01-13 2:36 ` weiqi at kylinos dot com.cn @ 2014-06-13 9:10 ` fweimer at redhat dot com 3 siblings, 0 replies; 5+ messages in thread From: fweimer at redhat dot com @ 2014-06-13 9:10 UTC (permalink / raw) To: glibc-bugs https://sourceware.org/bugzilla/show_bug.cgi?id=16410 Florian Weimer <fweimer at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |security- -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-06-13 9:10 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-01-08 1:43 [Bug nptl/16410] New: pthread_cond_timedwait has 70us latency when abstime already expired weiqi at kylinos dot com.cn 2014-01-08 1:49 ` [Bug nptl/16410] " weiqi at kylinos dot com.cn 2014-01-11 12:58 ` neleai at seznam dot cz 2014-01-13 2:36 ` weiqi at kylinos dot com.cn 2014-06-13 9:10 ` fweimer at redhat dot com
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).