This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 194103 - numactl --cpubind can't bind to CPUs 32-63
numactl --cpubind can't bind to CPUs 32-63
Status: CLOSED DUPLICATE of bug 193834
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: numactl (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Neil Horman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-05 16:03 EDT by Mike Stroyan
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-14 07:17:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mike Stroyan 2006-06-05 16:03:20 EDT
Description of problem:  numactl --cpubind can't bind to CPUs 32-63


Version-Release number of selected component (if applicable): 0.6.4-1.25


How reproducible:

  Problem is completely reproduceable on affected hardware.

Steps to Reproduce:
1. Run 
   strace -e trace=sched_setaffinity numactl --cpubind=4,5 numactl-0.9.8/numactl -s
   on a system with more than 32 CPUs.  The 0.9.8 version of numactl
   is used to illustrate what should happen and to display what does happen.
   This example has actual vs expected output for a 62 CPU superdome
   with 8 cells.  One cell has only 2 enabled CPUs, making node 4
   unusual in that it has CPUs 30 through 37.  It straddles the
   boundary between the accessible and inaccessible CPU bits.
   Normally some nodes are entirely usable and some are entirely
   unusable based on which CPUs they contain.
  
Actual results:

[root@worm0 ~]# strace -e trace=sched_setaffinity numactl --cpubind=4,5
numactl-0.9.8/numactl -s sched_setaffinity(8913, 64,  { c0000000, 3fff, 0, 0, 0,
0, 0, 0 }) = 0
policy: default
preferred node: current
physcpubind: 30 31
cpubind: 4
nodebind: 4
membind: 0 1 2 3 4 5 6 7 8

Expected results:

[root@worm0 ~]# LD_LIBRARY_PATH=numactl-0.9.8 strace -e trace=sched_setaffinity
numactl --cpubind=4,5 numactl-0.9.8/numactl -s
sched_setaffinity(0, 8,  { 3fffc0000000 }) = 0
policy: default
preferred node: current
physcpubind: 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
cpubind: 4 5
nodebind: 4 5
membind: 0 1 2 3 4 5 6 7 8


Additional info:
The problem in the 0.6.4-1.25 version of libnuma.so is that it only
uses 32 bits in the first 64 bits of the mask passed to 
sched_setaffinity().  Then it skips on to setting bits 64 bits in.

This problem and several other problems are fixed in the more current
versions of numactl available from ftp://ftp.suse.com/pub/people/ak/numa/ .
The most complete fix would be to incorporate a newer version of numactl.
Comment 1 Neil Horman 2006-06-14 07:17:31 EDT

*** This bug has been marked as a duplicate of 193843 ***
Comment 2 David Eisenstein 2006-06-14 10:50:26 EDT
This bug ticket may be a duplicate of some bug, but it's doubtful that it is a
duplicate of bug 193843.  Bug 193843 is a mailman bug for Fedora Legacy.
Comment 3 Mike Stroyan 2006-06-14 15:21:06 EDT

*** This bug has been marked as a duplicate of 193834 ***

Note You need to log in before you can comment on or make changes to this bug.