Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162132 - sched_setaffinity does not work from NPTL thread
Summary: sched_setaffinity does not work from NPTL thread
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-30 08:55 UTC by Francois-Xavier 'FiX' KOWALSKI
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-30 11:02:13 UTC

Attachments (Terms of Use)
test case (deleted)
2005-06-30 09:01 UTC, Francois-Xavier 'FiX' KOWALSKI
no flags Details
build t_affinity.c (deleted)
2005-06-30 09:02 UTC, Francois-Xavier 'FiX' KOWALSKI
no flags Details

Description Francois-Xavier 'FiX' KOWALSKI 2005-06-30 08:55:12 UTC
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 09:01:27 UTC
Created attachment 116162 [details]
test case

Comment 2 Francois-Xavier 'FiX' KOWALSKI 2005-06-30 09:02:00 UTC
Created attachment 116163 [details]
build t_affinity.c

Comment 3 Jakub Jelinek 2005-06-30 11:02:13 UTC
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 20:19:32 UTC
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 20:21:14 UTC
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 11:31:46 UTC
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.