Description of problem: Condition.wait timeout from threading.py cannot be set longer than 50 ms. What is the purpose of this limitation? If it is implemented for load balancing, there should be a way how to switch it off, because for tickless kernel this can increase number of wakeups and power consumption. This limitation also doesn't seem to be documented in the docs (http://docs.python.org/2/library/threading.html). Version-Release number of selected component (if applicable): python-libs-2.7.3-31 How reproducible: Always Steps to Reproduce: 1. Check time 2. Call wait with timeout set to e.g. 10 seconds 3. Check time Actual results: It timeouts in less than 50 ms. Expected results: Timeout after 10 seconds. Additional info: We encounter this behaviour in the tuned code (bug 917587) and it increases overhead of the code. Also adding this bug to power management bugs tracker.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Created attachment 735986 [details] Workaround The attached workaround worked for us. It extends the API, but it should be harmless extension. Calling the wait with the balancing=False will switch to the expected behaviour, calling it with the balancing=True (the default) will leave the current behaviour with the undocumented balancing hack.
Created attachment 736029 [details] Workaround Updated version that gives us the best power savings.
Reported upstream [1]. Let's wait for what the upstream has to say. The patch looks good and I can apply it downstream only if needed. [1] http://bugs.python.org/issue17748
(In reply to comment #4) > Reported upstream [1]. Let's wait for what the upstream has to say. The > patch looks good and I can apply it downstream only if needed. > > [1] http://bugs.python.org/issue17748 Thanks. For the record, I can confirm the python3 is not affected by this issue. But unfortunately we cannot easily port tuned to python3 - currently there are python2 only deps like configobj.
python-2.7.4-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/python-2.7.4-3.fc19
Package python-2.7.4-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-2.7.4-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-6231/python-2.7.4-3.fc19 then log in and leave karma (feedback).
python-2.7.4-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.