Bug 162132 - sched_setaffinity does not work from NPTL thread
sched_setaffinity does not work from NPTL thread
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-06-30 04:55 EDT by Francois-Xavier 'FiX' KOWALSKI
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-30 07:02:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test case (799 bytes, text/plain)
2005-06-30 05:01 EDT, Francois-Xavier 'FiX' KOWALSKI
no flags Details
build t_affinity.c (166 bytes, text/plain)
2005-06-30 05:02 EDT, Francois-Xavier 'FiX' KOWALSKI
no flags Details

  None (edit)
Description Francois-Xavier 'FiX' KOWALSKI 2005-06-30 04:55:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4

Description of problem:
sched_setaffinity does not apprar to succeed when run from an NPTL sub-thread.

	if( sched_setaffinity( 0, sizeof(cpu_set_t), &cpuset) != 0 )
		fprintf(stderr,"*** After sched_setaffinity() : %s\n", strerror(errno));
		fprintf(stderr,"After sched_setaffinity() : %s\n", strerror(errno));

strace'd execution shows:

Problem is that glibc's sched_setaffinity seems to retrieve some info from the current thread using getpid(), which use to return the LWP pid in pre-NPTL libs, but no longer in NPTL libs.

[pid 25997] write(2, "Before sched_setaffinity\n", 25Before sched_setaffinity
) = 25
[pid 25997] sched_getaffinity(25996, 128,  { f }) = 4
[pid 25997] write(2, "*** After sched_setaffinity() : "..., 49*** After sched_setaffinity() : Invalid argument
) = 49

Also, the returned code (>0) does not indicate an error (according to the man page) & while the errno value indicates an error...

As the syscall sched_setaffinity() was not even called, I assume that the result of this glibc call is that my thread is not bound...

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

How reproducible:

Steps to Reproduce:
1. build & run provided t_affinity.c under strace

Actual Results:  sched_setaffinity fails

Expected Results:  sched_setaffinity ok

Additional info:

kernel: 2.6.11-1.14_FC3smp (2 x EM64T CPU's, with HyperThreading activated)
Comment 1 Francois-Xavier 'FiX' KOWALSKI 2005-06-30 05:01:27 EDT
Created attachment 116162 [details]
test case
Comment 2 Francois-Xavier 'FiX' KOWALSKI 2005-06-30 05:02:00 EDT
Created attachment 116163 [details]
build t_affinity.c
Comment 3 Jakub Jelinek 2005-06-30 07:02:13 EDT
In threads you should be using pthread_setaffinity.
The call is failing, because you requested some CPUs outside of the set
the kernel can handle.
Comment 4 Francois-Xavier 'FiX' KOWALSKI 2005-07-07 16:19:32 EDT
Ok for the pthread_setaffinity, even if I seem to have few chances to find it by
myself (search on the fc2 box I have in my hands right now):

[fxk@tiffany fxk]% rgrep -nr pthread_setaffinity /usr/include
/usr/include/nptl/pthread.h:395:extern int pthread_setaffinity_np (pthread_t
__th, size_t __cpusetsize,

[fxk@tiffany fxk]% man pthread_setaffinity
No manual entry for pthread_setaffinity

But, disagree/need more info for the 2 following items (in order of importance),
before I could consider this items as closed/notabug:

1) Which interface can I use to fetch the number of usable CPU's on the box?  I
assumed that 0xfff..ffff was Ok (as put in my sample code) but this does not
look to be the right solution.  Any programmatic alternative?  Any URL I could
refer to -- if not in the manual pages -- to have a global look at what I can
expect in this pthread_xxx_(shoulbe be _np BTW) implementation?

2) sched_setaffinity man page says that success if 0 & -1 value in case
offailure, right ?  Seems that any non-zero value must also be considered as an
error.  Worth an update, IMO.
Comment 5 Francois-Xavier 'FiX' KOWALSKI 2005-07-07 16:21:14 EDT
Oh, forgot to mention that the sched_setaffinity() call from within an NPTL
sub-thread is working fine on rhel3, as far as I can observe.
Comment 6 Francois-Xavier 'FiX' KOWALSKI 2005-07-08 07:31:46 EDT
Now grepping on a rhel3u2 machine:

[fxk@lecter fxk]% rgrep -nr setaffinity /usr/include
/usr/include/asm/unistd.h:248:#define __NR_sched_setaffinity    241
/usr/include/bits/syscall.h:186:#define SYS_sched_setaffinity __NR_sched_setaffinity
/usr/include/sched.h:76:extern int sched_setaffinity (__pid_t __pid, __const
cpu_set_t *__mask)

so pthread_setaffinity did not exit at that time.

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