Bug 676927

Summary: tuna under RHEL6.0 can't set cpu affinity on large core count machines
Product: Red Hat Enterprise MRG Reporter: Matthew Whitehead <mwhitehe>
Component: realtime-utilitiesAssignee: Red Hat Real Time Maintenance <rt-maint>
Status: CLOSED ERRATA QA Contact: David Sommerseth <davids>
Severity: medium Docs Contact:
Priority: medium    
Version: DevelopmentCC: acme, bhu, iboverma, lgoncalv, ovasik, williams
Target Milestone: 2.0   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Previously, the Linux scheduler bindings provided by the python-schedutils package were unable to set the CPU affinity on systems with more than 64 cores. With this update, the package was modified to dynamically allocate the required space, allowing the CPU affinity to be successfully set on large core systems.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-23 15:04:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Matthew Whitehead 2011-02-11 21:12:41 UTC
Description of problem: tuna (beta) under RHEL6.0 won't set cpu affinity on released RHEL6.0 kernel.


Version-Release number of selected component (if applicable): RHEL6.0 kernel.


How reproducible: 100% once you have enough cpu cores (threshold still unknown).


Steps to Reproduce:
1. 'tuna --cpus=1 --threads=$$ --move'
2.
3.
  
Actual results: Will report an error. taskset will confirm the processor affinity mask is not set correctly.


Expected results: Should move the thread correctly.


Additional info:

Comment 1 Clark Williams 2011-02-14 18:34:10 UTC
Matt, 

What does the error say?

Comment 2 David Sommerseth 2011-02-22 09:09:04 UTC
Just a few more questions in addition to the one in comment#1,

a) When you use--threads=$$, it means that $$ is replaced by a real pid?

b) When using taskset, I presume you used 'taskset -p $PID'

c) Would 'grep Cpus_allowed: /proc/$PID/status' return the same value?

d) Which version of tuna did you try this on?  From which repository?

Comment 3 Matthew Whitehead 2011-03-22 03:42:18 UTC
This issue was fixed by Clark Williams with an ad-hoc patch to the python-linux-procfs packags.

Comment 8 Clark Williams 2011-05-20 15:34:08 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
* Cause: python-schedutils couldn't handle more than 64 cores
* Consequence: failed to set cpu affintiy on 80 core system
* Fix: dynamically allocate cpu_set_t data structures
* Result: successfully set cpu affinity on large core systems

Comment 9 Beth Uptagrafft 2011-05-20 15:53:58 UTC
python-schedutils-0.3-1.el6rt

Comment 10 Jaromir Hradilek 2011-05-20 18:06:57 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1 @@
-* Cause: python-schedutils couldn't handle more than 64 cores
+Previously, the Linux scheduler bindings provided by the python-schedutils package were unable to set the CPU affinity on systems with more than 64 cores. With this update, the package was modified to dynamically allocate the required space, allowing the CPU affinity to be successfully set on large core systems.-* Consequence: failed to set cpu affintiy on 80 core system
-* Fix: dynamically allocate cpu_set_t data structures
-* Result: successfully set cpu affinity on large core systems

Comment 13 David Sommerseth 2011-06-03 18:20:38 UTC
Verified by testing tuna according to comment #0.  No issues found on RHEL6.1.

[root@mrg39 ~]# rpm -q python-schedutils tuna
python-schedutils-0.3-1.el6rt.x86_64
tuna-0.10.1-2.el6rt.noarch

Tried to reproduce the issues using an older python-schedutils (0.2-2), but was not able to reproduce it.  This was tested on a quad socket quad core box.

Comment 14 errata-xmlrpc 2011-06-23 15:04:54 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2011-0894.html