Bug 162132
| Summary: | sched_setaffinity does not work from NPTL thread | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Francois-Xavier 'FiX' KOWALSKI <francois-xavier.kowalski> | ||||||
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 3 | CC: | drepper | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2005-06-30 11:02:13 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 116162 [details]
test case
Created attachment 116163 [details]
build t_affinity.c
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. 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. 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. 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. |
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)); else 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): glibc-2.3.5-0.fc3.1 How reproducible: Always Steps to Reproduce: 1. build & run provided t_affinity.c under strace 2. 3. 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)