For review: pthread_setaffinity_np.3

For review: pthread_setaffinity_np.3

[Michael Kerrisk]

Hi all,

Another new pthreads man page looking for reviewers.

Cheers,

Michael

.\" Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk
.\"     <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.TH PTHREAD_SETAFFINITY_NP 3 2008-11-04 "Linux" "Linux Programmer's Manual"
.SH NAME
pthread_setaffinity_np, pthread_getaffinity_np \- set/get
CPU affinity of a thread
.SH SYNOPSIS
.nf
.B #define _GNU_SOURCE
.B #include <pthread.h>

.BI "int pthread_setaffinity_np(pthread_t " thread ", size_t " cpusetsize ,
.BI "                           const cpu_set_t *" cpuset );
.BI "int pthread_getaffinity_np(pthread_t " thread ", size_t " cpusetsize ,
.BI "                           cpu_set_t *" cpuset );
.sp
Compile and link with \fI\-pthread\fP.
.SH DESCRIPTION
The
.BR pthread_setaffinity_np ()
sets the CPU affinity mask of the thread
.I thread
to the CPU set pointed to by
.IR cpuset .
If the call is successful,
and the thread is not currently running on one of the CPUs in
.IR cpuset ,
then it is migrated to one of those CPUs.

The
.BR pthread_getaffinity_np ()
function returns the CPU affinity mask of the thread
.I thread
in the buffer pointed to by
.IR cpuset .

The argument
.I cpusetsize
is the length (in bytes) of the buffer pointed to by
.IR cpuset .
Normally this argument would be specified as
.IR sizeof(cpu_set_t) .
The constant
.B CPU_SETSIZE
specifies a value one greater than the
maximum CPU number that can be stored in a CPU set.

For more details on CPU affinity masks,
as well as a description of a set of macros
that can be used to manipulate and inspect CPU sets, see
.BR sched_setaffinity (2)
for details.
.SH RETURN VALUE
On success, these functions return 0;
on error, they return a non-zero error number.
.SH ERRORS
.TP
.B EFAULT
A supplied memory address was invalid.
.TP
.B EINVAL
.RB ( pthread_setaffinity_np ())
The affinity bit mask
.I mask
contains no processors that are physically on the system.
.TP
.BR EINVAL
.RB ( pthread_setaffinity_np ())
.I cpuset
specified a CPU that was outside the range
permitted by the kernel data type
.\" cpumask_t
used to represent CPU sets.
.\" The raw sched_getaffinity() system call returns the size (in bytes)
.\" of the cpumask_t type.
This range is determined by the kernel configuration option
.BR CONFIG_NR_CPUS .
.TP
.B EINVAL
.RB ( pthread_getaffinity_np ()
.I cpusetsize
is smaller than the size of the affinity mask used by the kernel.
.TP
.B ESRCH
There is no thread matching
.IR thread
(e.g., perhaps that thread has already terminated and been joined).
.SH VERSIONS
These functions are provided by glibc since version 2.3.4.
.SH CONFORMING TO
These functions are non-standard GNU extensions.
.SH NOTES
These functions are interpreted on top of the
.BR sched_setaffinity (2)
and
.BR sched_getaffinity (2)
system calls.

In glibc 2.3.3 only,
versions of these functions were provided that did not have a
.I cpusetsize
argument.
Instead the CPU set size given to the underlying system calls was always
.IR sizeof(cpu_set_t) .

A new thread created by
.BR pthread_create ()
inherits a copy of its creator's CPU affinity mask.
.SH EXAMPLE
In the following program, the main thread uses
.BR pthread_setaffinity_np ()
to set its CPU affinity mask to include CPUs 0 to 7
(which may not all be available on the system),
and then calls
.BR pthread_getaffinity_np ()
to check the resulting CPU affinity mask of the thread.

.nf
#define _GNU_SOURCE
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>

#define errExitEN(en, msg)      { errno = en; perror(msg); \\
                                  exit(EXIT_FAILURE); }
int
main(int argc, char *argv[])
{
    int s, j;
    cpu_set_t cpuset;
    pthread_t thread;

    thread = pthread_self();

    /* Set affinity mask to include CPUs 0 to 7 */

    CPU_ZERO(&cpuset);
    for (j = 0; j < 8; j++)
        CPU_SET(j, &cpuset);

    s = pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
    if (s != 0)
        errExitEN(s, "sched_setaffinity");

    /* Check the actual affinity mask assigned to the thread */

    s = pthread_getaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
    if (s != 0)
        errExitEN(s, "sched_getaffinity");

    printf("Set returned by pthread_getaffinity_np() contained:\\n");
    for (j = 0; j < CPU_SETSIZE; j++)
        if (CPU_ISSET(j, &cpuset))
            printf("    CPU %d\\n", j);

    exit(EXIT_SUCCESS);
}
.fi
.SH SEE ALSO
.BR sched_getaffinity (2),
.BR sched_setaffinity (2),
.BR sched_getscheduler (2),
.BR pthread_getaffinity_np (3),
.BR pthread_setaffinity_np (3),
.BR cpuset (7),
.BR pthreads (7)
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Bert Wesarg]

On Tue, Nov 4, 2008 at 23:47, Michael Kerrisk
<mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> Hi all,
>
> Another new pthreads man page looking for reviewers.
>
> Cheers,
>
> Michael
>
> .\" Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk
> .\"     <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> .\"
> .\" Permission is granted to make and distribute verbatim copies of this
> .\" manual provided the copyright notice and this permission notice are
> .\" preserved on all copies.
> .\"
> .\" Permission is granted to copy and distribute modified versions of this
> .\" manual under the conditions for verbatim copying, provided that the
> .\" entire resulting derived work is distributed under the terms of a
> .\" permission notice identical to this one.
> .\"
> .\" Since the Linux kernel and libraries are constantly changing, this
> .\" manual page may be incorrect or out-of-date.  The author(s) assume no
> .\" responsibility for errors or omissions, or for damages resulting from
> .\" the use of the information contained herein.  The author(s) may not
> .\" have taken the same level of care in the production of this manual,
> .\" which is licensed free of charge, as they might when working
> .\" professionally.
> .\"
> .\" Formatted or processed versions of this manual, if unaccompanied by
> .\" the source, must acknowledge the copyright and authors of this work.
> .\"
> .TH PTHREAD_SETAFFINITY_NP 3 2008-11-04 "Linux" "Linux Programmer's Manual"
> .SH NAME
> pthread_setaffinity_np, pthread_getaffinity_np \- set/get
> CPU affinity of a thread
> .SH SYNOPSIS
> .nf
> .B #define _GNU_SOURCE
> .B #include <pthread.h>
>
> .BI "int pthread_setaffinity_np(pthread_t " thread ", size_t " cpusetsize ,
> .BI "                           const cpu_set_t *" cpuset );
> .BI "int pthread_getaffinity_np(pthread_t " thread ", size_t " cpusetsize ,
> .BI "                           cpu_set_t *" cpuset );
> .sp
> Compile and link with \fI\-pthread\fP.
> .SH DESCRIPTION
> The
> .BR pthread_setaffinity_np ()
> sets the CPU affinity mask of the thread
> .I thread
> to the CPU set pointed to by
> .IR cpuset .
> If the call is successful,
> and the thread is not currently running on one of the CPUs in
> .IR cpuset ,
> then it is migrated to one of those CPUs.
>
> The
> .BR pthread_getaffinity_np ()
> function returns the CPU affinity mask of the thread
> .I thread
> in the buffer pointed to by
> .IR cpuset .
>
> The argument
> .I cpusetsize
> is the length (in bytes) of the buffer pointed to by
> .IR cpuset .
> Normally this argument would be specified as
> .IR sizeof(cpu_set_t) .
> The constant
> .B CPU_SETSIZE
> specifies a value one greater than the
> maximum CPU number that can be stored in a CPU set.
Yeah, I like this naming confusion:

http://sourceware.org/ml/libc-alpha/2008-03/msg00080.html

>
> For more details on CPU affinity masks,
> as well as a description of a set of macros
> that can be used to manipulate and inspect CPU sets, see
> .BR sched_setaffinity (2)
> for details.
> .SH RETURN VALUE
> On success, these functions return 0;
> on error, they return a non-zero error number.
> .SH ERRORS
> .TP
> .B EFAULT
> A supplied memory address was invalid.
> .TP
> .B EINVAL
> .RB ( pthread_setaffinity_np ())
> The affinity bit mask
> .I mask
> contains no processors that are physically on the system.
> .TP
> .BR EINVAL
> .RB ( pthread_setaffinity_np ())
> .I cpuset
> specified a CPU that was outside the range
> permitted by the kernel data type
> .\" cpumask_t
> used to represent CPU sets.
> .\" The raw sched_getaffinity() system call returns the size (in bytes)
> .\" of the cpumask_t type.
Maybe a more detailed hint is needed, that cpumask_t and cpu_set_t are
the 'same', the former inside the kernel the latter in user space. But
I think such deep kernel internals doesn't belong to a API description
(because cpumask_t may gone, see 'struct cpumask' patches). I would
just replace cpumask_t by cpu_set_t.

> This range is determined by the kernel configuration option
> .BR CONFIG_NR_CPUS .
> .TP
> .B EINVAL
> .RB ( pthread_getaffinity_np ()
> .I cpusetsize
> is smaller than the size of the affinity mask used by the kernel.
> .TP
> .B ESRCH
> There is no thread matching
> .IR thread
> (e.g., perhaps that thread has already terminated and been joined).
> .SH VERSIONS
> These functions are provided by glibc since version 2.3.4.
> .SH CONFORMING TO
> These functions are non-standard GNU extensions.
> .SH NOTES
> These functions are interpreted on top of the
> .BR sched_setaffinity (2)
> and
> .BR sched_getaffinity (2)
> system calls.
>
> In glibc 2.3.3 only,
> versions of these functions were provided that did not have a
> .I cpusetsize
> argument.
> Instead the CPU set size given to the underlying system calls was always
> .IR sizeof(cpu_set_t) .
>
> A new thread created by
> .BR pthread_create ()
> inherits a copy of its creator's CPU affinity mask.
> .SH EXAMPLE
> In the following program, the main thread uses
> .BR pthread_setaffinity_np ()
> to set its CPU affinity mask to include CPUs 0 to 7
> (which may not all be available on the system),
> and then calls
> .BR pthread_getaffinity_np ()
> to check the resulting CPU affinity mask of the thread.
>
> .nf
> #define _GNU_SOURCE
> #include <pthread.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <errno.h>
>
> #define errExitEN(en, msg)      { errno = en; perror(msg); \\
>                                  exit(EXIT_FAILURE); }
> int
> main(int argc, char *argv[])
> {
>    int s, j;
>    cpu_set_t cpuset;
>    pthread_t thread;
>
>    thread = pthread_self();
>
>    /* Set affinity mask to include CPUs 0 to 7 */
>
>    CPU_ZERO(&cpuset);
>    for (j = 0; j < 8; j++)
>        CPU_SET(j, &cpuset);
>
>    s = pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
>    if (s != 0)
>        errExitEN(s, "sched_setaffinity");
>
>    /* Check the actual affinity mask assigned to the thread */
>
>    s = pthread_getaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
>    if (s != 0)
>        errExitEN(s, "sched_getaffinity");
>
>    printf("Set returned by pthread_getaffinity_np() contained:\\n");
>    for (j = 0; j < CPU_SETSIZE; j++)
>        if (CPU_ISSET(j, &cpuset))
>            printf("    CPU %d\\n", j);
>
>    exit(EXIT_SUCCESS);
> }
> .fi
> .SH SEE ALSO
> .BR sched_getaffinity (2),
> .BR sched_setaffinity (2),
> .BR sched_getscheduler (2),
> .BR pthread_getaffinity_np (3),
> .BR pthread_setaffinity_np (3),
Maybe pthread__attr_{set,get}affinity_np, too.

> .BR cpuset (7),
> .BR pthreads (7)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Michael Kerrisk]

Bert,

Thanks for looking the page over.

[...]

>> The argument
>> .I cpusetsize
>> is the length (in bytes) of the buffer pointed to by
>> .IR cpuset .
>> Normally this argument would be specified as
>> .IR sizeof(cpu_set_t) .
>> The constant
>> .B CPU_SETSIZE
>> specifies a value one greater than the
>> maximum CPU number that can be stored in a CPU set.
> Yeah, I like this naming confusion:
>
> http://sourceware.org/ml/libc-alpha/2008-03/msg00080.html
>
>>
>> For more details on CPU affinity masks,
>> as well as a description of a set of macros
>> that can be used to manipulate and inspect CPU sets, see
>> .BR sched_setaffinity (2)
>> for details.
>> .SH RETURN VALUE
>> On success, these functions return 0;
>> on error, they return a non-zero error number.
>> .SH ERRORS
>> .TP
>> .B EFAULT
>> A supplied memory address was invalid.
>> .TP
>> .B EINVAL
>> .RB ( pthread_setaffinity_np ())
>> The affinity bit mask
>> .I mask
>> contains no processors that are physically on the system.
>> .TP
>> .BR EINVAL
>> .RB ( pthread_setaffinity_np ())
>> .I cpuset
>> specified a CPU that was outside the range
>> permitted by the kernel data type
>> .\" cpumask_t
>> used to represent CPU sets.
>> .\" The raw sched_getaffinity() system call returns the size (in bytes)
>> .\" of the cpumask_t type.
> Maybe a more detailed hint is needed, that cpumask_t and cpu_set_t are
> the 'same', the former inside the kernel the latter in user space. But
> I think such deep kernel internals doesn't belong to a API description
> (because cpumask_t may gone, see 'struct cpumask' patches). I would
> just replace cpumask_t by cpu_set_t.

But they are not the same think (which makes things a little weird).
The kernel's cpumask_t is

typedef struct { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;

Where NR_CPUS depends on the CONFIG_NR_CPUS config option.

But in userspace, cpu_set_t is

# define __CPU_SETSIZE  1024
# define __NCPUBITS     (8 * sizeof (__cpu_mask))

/* Data structure to describe CPU mask.  */
typedef struct
{
  __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS];
} cpu_set_t;

That is, cpu_mask_t is always 1024 bits, but cpumask_t may be (and
typically is) smaller.

[...]

>> .SH SEE ALSO
>> .BR sched_getaffinity (2),
>> .BR sched_setaffinity (2),
>> .BR sched_getscheduler (2),
>> .BR pthread_getaffinity_np (3),
>> .BR pthread_setaffinity_np (3),
> Maybe pthread__attr_{set,get}affinity_np, too.
>
>> .BR cpuset (7),
>> .BR pthreads (7)

Good idea.  And in fact, I had already changed it to:

.SH SEE ALSO
.BR sched_getcpu (3),
.BR sched_setaffinity (2),
.BR sched_setscheduler (2),
.BR pthread_attr_setaffinity_np (3),
.BR pthread_self (3),
.BR cpuset (7),
.BR pthreads (7)

(Some "get" functions disappeared from the list since they are
documented in the corresponding "set" page.)

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Loic Domaigne]

Hi Michael,

this one is not 'straightforward' for me as I needed to look into the 
glibc and kernel source...

I am not very knowledgeable in that area, so my review comments are in 
consequence...

Cheers,
Loïc
--

> .\" Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk
> .\"     <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> .\"
> .\" Permission is granted to make and distribute verbatim copies of this
> .\" manual provided the copyright notice and this permission notice are
> .\" preserved on all copies.
> .\"
> .\" Permission is granted to copy and distribute modified versions of this
> .\" manual under the conditions for verbatim copying, provided that the
> .\" entire resulting derived work is distributed under the terms of a
> .\" permission notice identical to this one.
> .\"
> .\" Since the Linux kernel and libraries are constantly changing, this
> .\" manual page may be incorrect or out-of-date.  The author(s) assume no
> .\" responsibility for errors or omissions, or for damages resulting from
> .\" the use of the information contained herein.  The author(s) may not
> .\" have taken the same level of care in the production of this manual,
> .\" which is licensed free of charge, as they might when working
> .\" professionally.
> .\"
> .\" Formatted or processed versions of this manual, if unaccompanied by
> .\" the source, must acknowledge the copyright and authors of this work.
> .\"
> .TH PTHREAD_SETAFFINITY_NP 3 2008-11-04 "Linux" "Linux Programmer's Manual"
> .SH NAME
> pthread_setaffinity_np, pthread_getaffinity_np \- set/get
> CPU affinity of a thread
> .SH SYNOPSIS
> .nf
> .B #define _GNU_SOURCE
> .B #include <pthread.h>
> 
> .BI "int pthread_setaffinity_np(pthread_t " thread ", size_t " cpusetsize ,
> .BI "                           const cpu_set_t *" cpuset );
> .BI "int pthread_getaffinity_np(pthread_t " thread ", size_t " cpusetsize ,
> .BI "                           cpu_set_t *" cpuset );
> .sp
> Compile and link with \fI\-pthread\fP.
> .SH DESCRIPTION
> The
> .BR pthread_setaffinity_np ()
> sets the CPU affinity mask of the thread
> .I thread
> to the CPU set pointed to by
> .IR cpuset .
> If the call is successful,
> and the thread is not currently running on one of the CPUs in
> .IR cpuset ,
> then it is migrated to one of those CPUs.
> 
> The
> .BR pthread_getaffinity_np ()
> function returns the CPU affinity mask of the thread
> .I thread
> in the buffer pointed to by
> .IR cpuset .
> 
> The argument
> .I cpusetsize
> is the length (in bytes) of the buffer pointed to by
> .IR cpuset .
> Normally this argument would be specified as
> .IR sizeof(cpu_set_t) .
> The constant
> .B CPU_SETSIZE
> specifies a value one greater than the
> maximum CPU number that can be stored in a CPU set.

I came independently to the same conclusion than you. AFAICS,glibc 
defines the cpu_set_t to be a 1024 bits long structure. But the kernel 
defines the corresponding structure to be a bit field of appropriate 
length to store NR_CPUS.

Interesting enough, the exact size of the kernel structure is determined 
by the glibc on the 1st call to pthread_setaffinity_np().

We'll run into troubles if run this on a server with more than 1K core ;-)

> For more details on CPU affinity masks,
> as well as a description of a set of macros
> that can be used to manipulate and inspect CPU sets, see
> .BR sched_setaffinity (2)
> for details.
> .SH RETURN VALUE
> On success, these functions return 0;
> on error, they return a non-zero error number.
> .SH ERRORS
> .TP
> .B EFAULT
> A supplied memory address was invalid.
> .TP
> .B EINVAL
> .RB ( pthread_setaffinity_np ())
> The affinity bit mask
> .I mask
> contains no processors that are physically on the system.

If I got it right, it seems that Linux supports (or is preparing) 
hotplug of CPUs cards... So when you say that "mask contains no 
processors that are physically on the system", it should be understood: 
at the point of time where pthread_setaffinity_np() has been issued.

> .TP
> .BR EINVAL
> .RB ( pthread_setaffinity_np ())
> .I cpuset
> specified a CPU that was outside the range
> permitted by the kernel data type
> .\" cpumask_t
> used to represent CPU sets.
> .\" The raw sched_getaffinity() system call returns the size (in bytes)
> .\" of the cpumask_t type.
> This range is determined by the kernel configuration option
> .BR CONFIG_NR_CPUS .

True. But what does it mean for an application programmer? That I am 
requesting a processor which is outside of the set supported by the 
kernel (structure). Strictly speaking, this processor could be 
physically present.

So, If I sum-up the two EINVAL cases above, I get something like:

The affinity bit mask <code>mask</code> contains no processors that are 
physically on the system, or contains a processor outside of the set 
supported by the kernel.


> .TP
> .B EINVAL
> .RB ( pthread_getaffinity_np ()
> .I cpusetsize
> is smaller than the size of the affinity mask used by the kernel.
> .TP
> .B ESRCH
> There is no thread matching
> .IR thread
> (e.g., perhaps that thread has already terminated and been joined).
> .SH VERSIONS
> These functions are provided by glibc since version 2.3.4.
> .SH CONFORMING TO
> These functions are non-standard GNU extensions.
> .SH NOTES
> These functions are interpreted on top of the
> .BR sched_setaffinity (2)
> and
> .BR sched_getaffinity (2)
> system calls.
> 
> In glibc 2.3.3 only,
> versions of these functions were provided that did not have a
> .I cpusetsize
> argument.
> Instead the CPU set size given to the underlying system calls was always
> .IR sizeof(cpu_set_t) .

That's funny. Didn't you mention above that "the cpusetsize should be
sizeof(cpu_set_t)"... So for now, it's not that much different ;-)

> A new thread created by
> .BR pthread_create ()
> inherits a copy of its creator's CPU affinity mask.
> .SH EXAMPLE
> In the following program, the main thread uses
> .BR pthread_setaffinity_np ()
> to set its CPU affinity mask to include CPUs 0 to 7
> (which may not all be available on the system),
> and then calls
> .BR pthread_getaffinity_np ()
> to check the resulting CPU affinity mask of the thread.
> 
> .nf
> #define _GNU_SOURCE
> #include <pthread.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <errno.h>
> 
> #define errExitEN(en, msg)      { errno = en; perror(msg); \\
>                                   exit(EXIT_FAILURE); }
> int
> main(int argc, char *argv[])
> {
>     int s, j;
>     cpu_set_t cpuset;
>     pthread_t thread;
> 
>     thread = pthread_self();
> 
>     /* Set affinity mask to include CPUs 0 to 7 */
> 
>     CPU_ZERO(&cpuset);
>     for (j = 0; j < 8; j++)
>         CPU_SET(j, &cpuset);
> 
>     s = pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
>     if (s != 0)
>         errExitEN(s, "sched_setaffinity");
> 
>     /* Check the actual affinity mask assigned to the thread */
> 
>     s = pthread_getaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
>     if (s != 0)
>         errExitEN(s, "sched_getaffinity");
> 
>     printf("Set returned by pthread_getaffinity_np() contained:\\n");
>     for (j = 0; j < CPU_SETSIZE; j++)
>         if (CPU_ISSET(j, &cpuset))
>             printf("    CPU %d\\n", j);
> 
>     exit(EXIT_SUCCESS);
> }
> .fi

This might be obvious to all of you, but it wasn't to me... The CPU set 
used for the affinity is the intersection of the set passed to 
pthread_setaffinity_np() and the set of processors supported by the 
kernel...

That's why your example shall work, even if the system where it runs has 
less than 8 processors.

> .SH SEE ALSO
> .BR sched_getaffinity (2),
> .BR sched_setaffinity (2),
> .BR sched_getscheduler (2),
> .BR pthread_getaffinity_np (3),
> .BR pthread_setaffinity_np (3),
> .BR cpuset (7),
> .BR pthreads (7)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Bert Wesarg]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 3669 bytes --]

On Sat, Nov 8, 2008 at 23:31, Loic Domaigne <tech@domaigne.com> wrote:
> Hi Michael,
>
> this one is not 'straightforward' for me as I needed to look into the glibc
> and kernel source...
>
> I am not very knowledgeable in that area, so my review comments are in
> consequence...
>
> Cheers,
> Loïc
> --
>
>> .\" Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk
>> .\"     <mtk.manpages@gmail.com>
>> .\"
>> .\" Permission is granted to make and distribute verbatim copies of this
>> .\" manual provided the copyright notice and this permission notice are
>> .\" preserved on all copies.
>> .\"
>> .\" Permission is granted to copy and distribute modified versions of this
>> .\" manual under the conditions for verbatim copying, provided that the
>> .\" entire resulting derived work is distributed under the terms of a
>> .\" permission notice identical to this one.
>> .\"
>> .\" Since the Linux kernel and libraries are constantly changing, this
>> .\" manual page may be incorrect or out-of-date.  The author(s) assume no
>> .\" responsibility for errors or omissions, or for damages resulting from
>> .\" the use of the information contained herein.  The author(s) may not
>> .\" have taken the same level of care in the production of this manual,
>> .\" which is licensed free of charge, as they might when working
>> .\" professionally.
>> .\"
>> .\" Formatted or processed versions of this manual, if unaccompanied by
>> .\" the source, must acknowledge the copyright and authors of this work.
>> .\"
>> .TH PTHREAD_SETAFFINITY_NP 3 2008-11-04 "Linux" "Linux Programmer's
>> Manual"
>> .SH NAME
>> pthread_setaffinity_np, pthread_getaffinity_np \- set/get
>> CPU affinity of a thread
>> .SH SYNOPSIS
>> .nf
>> .B #define _GNU_SOURCE
>> .B #include <pthread.h>
>>
>> .BI "int pthread_setaffinity_np(pthread_t " thread ", size_t " cpusetsize
>> ,
>> .BI "                           const cpu_set_t *" cpuset );
>> .BI "int pthread_getaffinity_np(pthread_t " thread ", size_t " cpusetsize
>> ,
>> .BI "                           cpu_set_t *" cpuset );
>> .sp
>> Compile and link with \fI\-pthread\fP.
>> .SH DESCRIPTION
>> The
>> .BR pthread_setaffinity_np ()
>> sets the CPU affinity mask of the thread
>> .I thread
>> to the CPU set pointed to by
>> .IR cpuset .
>> If the call is successful,
>> and the thread is not currently running on one of the CPUs in
>> .IR cpuset ,
>> then it is migrated to one of those CPUs.
>>
>> The
>> .BR pthread_getaffinity_np ()
>> function returns the CPU affinity mask of the thread
>> .I thread
>> in the buffer pointed to by
>> .IR cpuset .
>>
>> The argument
>> .I cpusetsize
>> is the length (in bytes) of the buffer pointed to by
>> .IR cpuset .
>> Normally this argument would be specified as
>> .IR sizeof(cpu_set_t) .
>> The constant
>> .B CPU_SETSIZE
>> specifies a value one greater than the
>> maximum CPU number that can be stored in a CPU set.
>
> I came independently to the same conclusion than you. AFAICS,glibc defines
> the cpu_set_t to be a 1024 bits long structure. But the kernel defines the
> corresponding structure to be a bit field of appropriate length to store
> NR_CPUS.
>
> Interesting enough, the exact size of the kernel structure is determined by
> the glibc on the 1st call to pthread_setaffinity_np().
>
> We'll run into troubles if run this on a server with more than 1K core ;-)
Thats why glibc provides a new set of function to handle cpu_set_t
with more than 1K bits.
Look for the definitions of macros with a _S suffix in <sched.h>.

Bert
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±™©âžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br	šê+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹\x1e®w¥¢¸?™¨è­Ú&¢)ߢ^[f

Re: For review: pthread_setaffinity_np.3

[Michael Kerrisk]

Hi Bert,

>>> The argument
>>> .I cpusetsize
>>> is the length (in bytes) of the buffer pointed to by
>>> .IR cpuset .
>>> Normally this argument would be specified as
>>> .IR sizeof(cpu_set_t) .
>>> The constant
>>> .B CPU_SETSIZE
>>> specifies a value one greater than the
>>> maximum CPU number that can be stored in a CPU set.
>>
>> I came independently to the same conclusion than you. AFAICS,glibc defines
>> the cpu_set_t to be a 1024 bits long structure. But the kernel defines the
>> corresponding structure to be a bit field of appropriate length to store
>> NR_CPUS.
>>
>> Interesting enough, the exact size of the kernel structure is determined by
>> the glibc on the 1st call to pthread_setaffinity_np().
>>
>> We'll run into troubles if run this on a server with more than 1K core ;-)
> Thats why glibc provides a new set of function to handle cpu_set_t
> with more than 1K bits.
> Look for the definitions of macros with a _S suffix in <sched.h>.

Thanks for alerting me to this.  Of course those macros need
documenting.  I've pretty much completed a page documenting them.
Would you be willing to check it over?

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Bert Wesarg]

On Thu, Nov 13, 2008 at 03:30, Michael Kerrisk
<mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> Hi Bert,
>
>>>> The argument
>>>> .I cpusetsize
>>>> is the length (in bytes) of the buffer pointed to by
>>>> .IR cpuset .
>>>> Normally this argument would be specified as
>>>> .IR sizeof(cpu_set_t) .
>>>> The constant
>>>> .B CPU_SETSIZE
>>>> specifies a value one greater than the
>>>> maximum CPU number that can be stored in a CPU set.
>>>
>>> I came independently to the same conclusion than you. AFAICS,glibc defines
>>> the cpu_set_t to be a 1024 bits long structure. But the kernel defines the
>>> corresponding structure to be a bit field of appropriate length to store
>>> NR_CPUS.
>>>
>>> Interesting enough, the exact size of the kernel structure is determined by
>>> the glibc on the 1st call to pthread_setaffinity_np().
>>>
>>> We'll run into troubles if run this on a server with more than 1K core ;-)
>> Thats why glibc provides a new set of function to handle cpu_set_t
>> with more than 1K bits.
>> Look for the definitions of macros with a _S suffix in <sched.h>.
>
> Thanks for alerting me to this.  Of course those macros need
> documenting.  I've pretty much completed a page documenting them.
> Would you be willing to check it over?
Sure.

Bert
>
> Cheers,
>
> Michael
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
> man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
> Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Michael Kerrisk]

Hi Loïc,

> this one is not 'straightforward' for me as I needed to look into the glibc
> and kernel source...
>
> I am not very knowledgeable in that area, so my review comments are in
> consequence...

No problem.  Thanks for looking over the page.  My responses below.

[...]

>> The argument
>> .I cpusetsize
>> is the length (in bytes) of the buffer pointed to by
>> .IR cpuset .
>> Normally this argument would be specified as
>> .IR sizeof(cpu_set_t) .
>> The constant
>> .B CPU_SETSIZE
>> specifies a value one greater than the
>> maximum CPU number that can be stored in a CPU set.
>
> I came independently to the same conclusion than you. AFAICS,glibc defines
> the cpu_set_t to be a 1024 bits long structure. But the kernel defines the
> corresponding structure to be a bit field of appropriate length to store
> NR_CPUS.
>
> Interesting enough, the exact size of the kernel structure is determined by
> the glibc on the 1st call to pthread_setaffinity_np().
>
> We'll run into troubles if run this on a server with more than 1K core ;-)

As noted by Bert Wesarg, recent glibc provides some macros to deal
with this, and I created CPU_SET.3 to document them.

[...]

>> .TP
>> .B EINVAL
>> .RB ( pthread_setaffinity_np ())
>> The affinity bit mask
>> .I mask
>> contains no processors that are physically on the system.
>
> If I got it right, it seems that Linux supports (or is preparing) hotplug of
> CPUs cards... So when you say that "mask contains no processors that are
> physically on the system", it should be understood: at the point of time
> where pthread_setaffinity_np() has been issued.

To hint at this, I added the word "currently"

==
.TP
.B EINVAL
.RB ( pthread_setaffinity_np ())
The affinity bit mask
.I mask
contains no processors that are currently physically on the system.
==

> .TP
>> .BR EINVAL
>> .RB ( pthread_setaffinity_np ())
>> .I cpuset
>> specified a CPU that was outside the range
>> permitted by the kernel data type
>> .\" cpumask_t
>> used to represent CPU sets.
>> .\" The raw sched_getaffinity() system call returns the size (in bytes)
>> .\" of the cpumask_t type.
>> This range is determined by the kernel configuration option
>> .BR CONFIG_NR_CPUS .
>
> True. But what does it mean for an application programmer? That I am
> requesting a processor which is outside of the set supported by the kernel
> (structure). Strictly speaking, this processor could be physically present.
>
> So, If I sum-up the two EINVAL cases above, I get something like:
>
> The affinity bit mask <code>mask</code> contains no processors that are
> physically on the system, or contains a processor outside of the set
> supported by the kernel.

Okay, I agree it could be clearer.  So, what I did was reword the
second EINVAL error somewhat:

==
.TP
.BR EINVAL
.RB ( pthread_setaffinity_np ())
.I cpuset
specified a CPU that was outside the set supported by the kernel.
(The kernel configuration option
.BR CONFIG_NR_CPUS
defines the range of the set supported by the kernel data type
.\" cpumask_t
used to represent CPU sets.)
==

>> In glibc 2.3.3 only,
>> versions of these functions were provided that did not have a
>> .I cpusetsize
>> argument.
>> Instead the CPU set size given to the underlying system calls was always
>> .IR sizeof(cpu_set_t) .
>
> That's funny. Didn't you mention above that "the cpusetsize should be
> sizeof(cpu_set_t)"... So for now, it's not that much different ;-)

Yes, once could get that impression.  In the light of your comments,
Bert's comments, and my changes (CPU_SET.3), elsewhere in the page, I
have now added this explanation elsewhere in the page:

==
The argument
.I cpusetsize
is the length (in bytes) of the buffer pointed to by
.IR cpuset .
Typically, this argument would be specified as
.IR sizeof(cpu_set_t) .
(It may be some other value, if using the macros described in
.BR CPU_SET (3)
for dynamically allocating a CPU set.)
==

[...]

>>    /* Check the actual affinity mask assigned to the thread */
>>
>>    s = pthread_getaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
>>    if (s != 0)
>>        errExitEN(s, "sched_getaffinity");
>>
>>    printf("Set returned by pthread_getaffinity_np() contained:\\n");
>>    for (j = 0; j < CPU_SETSIZE; j++)
>>        if (CPU_ISSET(j, &cpuset))
>>            printf("    CPU %d\\n", j);
>>
>>    exit(EXIT_SUCCESS);
>> }
>> .fi
>
> This might be obvious to all of you, but it wasn't to me... The CPU set used
> for the affinity is the intersection of the set passed to
> pthread_setaffinity_np() and the set of processors supported by the
> kernel...
>
> That's why your example shall work, even if the system where it runs has
> less than 8 processors.

It's true.  The page should say something to make this clearer.  I
added this text to NOTES

       After a call to  pthread_setaffinity_np(3),  the  set  of
       CPUs  on which the thread will actually run is the inter-
       section of the set specified in the cpuset  argument  and
       the set of CPUs actually present on the system.  The sys-
       tem may further restrict the set of  CPUs  on  which  the
       thread  runs  if  the  "cpuset"  mechanism  described  in
       cpuset(7) is  being  used.   These  restrictions  on  the
       actual  set  of  CPUs  on  which  the thread will run are
       silently imposed by the kernel.

Thanks for these insightful comments Loïc!

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Michael Kerrisk]

[CC += "Paul Jackson" <pj-sJ/iWh9BUns@public.gmane.org>, who might want to Ack the patch below]

>> This might be obvious to all of you, but it wasn't to me... The CPU set used
>> for the affinity is the intersection of the set passed to
>> pthread_setaffinity_np() and the set of processors supported by the
>> kernel...
>>
>> That's why your example shall work, even if the system where it runs has
>> less than 8 processors.
>
> It's true.  The page should say something to make this clearer.  I
> added this text to NOTES
>
>       After a call to  pthread_setaffinity_np(3),  the  set  of
>       CPUs  on which the thread will actually run is the inter-
>       section of the set specified in the cpuset  argument  and
>       the set of CPUs actually present on the system.  The sys-
>       tem may further restrict the set of  CPUs  on  which  the
>       thread  runs  if  the  "cpuset"  mechanism  described  in
>       cpuset(7) is  being  used.   These  restrictions  on  the
>       actual  set  of  CPUs  on  which  the thread will run are
>       silently imposed by the kernel.

Of course, the sched_setaffinity.2 page also deserves similar text.  I
made the change below.

Look ok?

Cheers,

Michael

--- a/man2/sched_setaffinity.2
+++ b/man2/sched_setaffinity.2

@@ -122,7 +122,10 @@ A supplied memory address was invalid.
 .B EINVAL
 The affinity bit mask
 .I mask
-contains no processors that are physically on the system.
+contains no processors that are currently physically on the system
+and permitted to the process according to any restrictions that
+may be imposed by the "cpuset" mechanism described in
+.BR cpuset (7).
 .TP
 .B EINVAL
 .RB ( sched_getaffinity ()
@@ -157,6 +160,19 @@ argument was removed, but was then restored in glibc 2.3.4,
 with type
 .SH "CONFORMING TO"
 These system calls are Linux-specific.
 .SH "NOTES"
+After a call to
+.BR sched_setaffinity (),
+the set of CPUs on which the process will actually run is
+the intersection of the set specified in the
+.I mask
+argument and the set of CPUs actually present on the system.
+The system may further restrict the set of CPUs on which the process
+runs if the "cpuset" mechanism described in
+.BR cpuset (7)
+is being used.
+These restrictions on the actual set of CPUs on which the process
+will run are silently imposed by the kernel.
+
 .BR sched_setscheduler (2)
 has a description of the Linux scheduling scheme.
 .PP
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Delivery Status Notification (Failure)

[Michael Kerrisk]

Bother!  Mail to Paul Jackson bounced from the last address I had for
him.  Anyway know an up-to-date address?

On Fri, Nov 14, 2008 at 10:38 AM, Mail Delivery Subsystem
<mailer-daemon-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> This is an automatically generated Delivery Status Notification
>
> Delivery to the following recipient failed permanently:
>
>     pj-sJ/iWh9BUns@public.gmane.org
>
> Technical details of permanent failure:
> Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 cuda_nsu 5.7.1 <pj-sJ/iWh9BUns@public.gmane.org>: Recipient address rejected: THIS USER IS NO LONGER WITH SGI. CONTACT help-sJ/iWh9BUns@public.gmane.org IF YOU NEED INFO. (state 14).
>
>   ----- Original message -----
>
> Received: by 10.180.222.1 with SMTP id u1mr289004bkg.62.1226677136648;
>        Fri, 14 Nov 2008 07:38:56 -0800 (PST)
> Received: by 10.181.33.19 with HTTP; Fri, 14 Nov 2008 07:38:56 -0800 (PST)
> Message-ID: <cfd18e0f0811140738i33f2c671kc99bbb7750f2fa44-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Date: Fri, 14 Nov 2008 10:38:56 -0500
> From: "Michael Kerrisk" <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Reply-To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> To: "Loic Domaigne" <tech-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>, "Paul Jackson" <pj-sJ/iWh9BUns@public.gmane.org>
> Subject: Re: For review: pthread_setaffinity_np.3
> Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, josv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
>        "brian m. carlson" <sandals-spVehEqlxw627WubY2PhZQivdfXVPZ6z@public.gmane.org>,
>        "Bert Wesarg" <bert.wesarg-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>,
>        "Stefan Puiu" <stefanpuiuro-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>,
>        "Karsten Weiss" <K.Weiss-Pt+Xe7GJXK+P2YhJcF5u+nqWYbMAw+HU@public.gmane.org>
> In-Reply-To: <cfd18e0f0811140704l18e5741fgdbb5a6c52fb8cbe7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> References: <cfd18e0f0811041447w57dd5de4he68ca780ed963074-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>         <4916133A.8060209-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>
>         <cfd18e0f0811140704l18e5741fgdbb5a6c52fb8cbe7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>
> [CC += "Paul Jackson" <pj-sJ/iWh9BUns@public.gmane.org>, who might want to Ack the patch below]
>
>>> This might be obvious to all of you, but it wasn't to me... The CPU set used
>>> for the affinity is the intersection of the set passed to
>>> pthread_setaffinity_np() and the set of processors supported by the
>>> kernel...
>>>
>>> That's why your example shall work, even if the system where it runs has
>>> less than 8 processors.
>>
>
>   ----- Message truncated -----
>
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Michael Kerrisk]

And, for completeness: the current version of the page is below.

Thanks,

Michael

.\" Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk
.\"     <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.TH PTHREAD_SETAFFINITY_NP 3 2008-11-14 "Linux" "Linux Programmer's Manual"
.SH NAME
pthread_setaffinity_np, pthread_getaffinity_np \- set/get
CPU affinity of a thread
.SH SYNOPSIS
.nf
.B #define _GNU_SOURCE
.B #include <pthread.h>

.BI "int pthread_setaffinity_np(pthread_t " thread ", size_t " cpusetsize ,
.BI "                           const cpu_set_t *" cpuset );
.BI "int pthread_getaffinity_np(pthread_t " thread ", size_t " cpusetsize ,
.BI "                           cpu_set_t *" cpuset );
.sp
Compile and link with \fI\-pthread\fP.
.SH DESCRIPTION
The
.BR pthread_setaffinity_np ()
sets the CPU affinity mask of the thread
.I thread
to the CPU set pointed to by
.IR cpuset .
If the call is successful,
and the thread is not currently running on one of the CPUs in
.IR cpuset ,
then it is migrated to one of those CPUs.

The
.BR pthread_getaffinity_np ()
function returns the CPU affinity mask of the thread
.I thread
in the buffer pointed to by
.IR cpuset .

For more details on CPU affinity masks, see
.BR sched_setaffinity (2).
For a description of a set of macros
that can be used to manipulate and inspect CPU sets, see
.BR CPU_SET (3).

The argument
.I cpusetsize
is the length (in bytes) of the buffer pointed to by
.IR cpuset .
Typically, this argument would be specified as
.IR sizeof(cpu_set_t) .
(It may be some other value, if using the macros described in
.BR CPU_SET (3)
for dynamically allocating a CPU set.)
.SH RETURN VALUE
On success, these functions return 0;
on error, they return a non-zero error number.
.SH ERRORS
.TP
.B EFAULT
A supplied memory address was invalid.
.TP
.B EINVAL
.RB ( pthread_setaffinity_np ())
The affinity bit mask
.I mask
contains no processors that are currently physically on the system
and permitted to the thread according to any restrictions that
may be imposed by the "cpuset" mechanism described in
.BR cpuset (7).
.TP
.BR EINVAL
.RB ( pthread_setaffinity_np ())
.I cpuset
specified a CPU that was outside the set supported by the kernel.
(The kernel configuration option
.BR CONFIG_NR_CPUS
defines the range of the set supported by the kernel data type
.\" cpumask_t
used to represent CPU sets.)
.\" The raw sched_getaffinity() system call returns the size (in bytes)
.\" of the cpumask_t type.
.TP
.B EINVAL
.RB ( pthread_getaffinity_np ())
.I cpusetsize
is smaller than the size of the affinity mask used by the kernel.
.TP
.B ESRCH
There is no thread matching
.IR thread
(e.g., perhaps that thread has already terminated and been joined).
.SH VERSIONS
These functions are provided by glibc since version 2.3.4.
.SH CONFORMING TO
These functions are non-standard GNU extensions;
hence the suffix "_np" (non-portable) in the names.
.SH NOTES
After a call to
.BR pthread_setaffinity_np (),
the set of CPUs on which the thread will actually run is
the intersection of the set specified in the
.I cpuset
argument and the set of CPUs actually present on the system.
The system may further restrict the set of CPUs on which the thread
runs if the "cpuset" mechanism described in
.BR cpuset (7)
is being used.
These restrictions on the actual set of CPUs on which the thread
will run are silently imposed by the kernel.

These functions are implemented on top of the
.BR sched_setaffinity (2)
and
.BR sched_getaffinity (2)
system calls.

In glibc 2.3.3 only,
versions of these functions were provided that did not have a
.I cpusetsize
argument.
Instead the CPU set size given to the underlying system calls was always
.IR sizeof(cpu_set_t) .

A new thread created by
.BR pthread_create ()
inherits a copy of its creator's CPU affinity mask.
.SH EXAMPLE
In the following program, the main thread uses
.BR pthread_setaffinity_np ()
to set its CPU affinity mask to include CPUs 0 to 7
(which may not all be available on the system),
and then calls
.BR pthread_getaffinity_np ()
to check the resulting CPU affinity mask of the thread.

.nf
#define _GNU_SOURCE
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>

#define handle_error_en(en, msg) \\
        do { errno = en; perror(msg); exit(EXIT_FAILURE); } while (0)

int
main(int argc, char *argv[])
{
    int s, j;
    cpu_set_t cpuset;
    pthread_t thread;

    thread = pthread_self();

    /* Set affinity mask to include CPUs 0 to 7 */

    CPU_ZERO(&cpuset);
    for (j = 0; j < 8; j++)
        CPU_SET(j, &cpuset);

    s = pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
    if (s != 0)
        handle_error_en(s, "pthread_setaffinity_np");

    /* Check the actual affinity mask assigned to the thread */

    s = pthread_getaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
    if (s != 0)
        handle_error_en(s, "pthread_getaffinity_np");

    printf("Set returned by pthread_getaffinity_np() contained:\\n");
    for (j = 0; j < CPU_SETSIZE; j++)
        if (CPU_ISSET(j, &cpuset))
            printf("    CPU %d\\n", j);

    exit(EXIT_SUCCESS);
}
.fi
.SH SEE ALSO
.BR sched_getcpu (3),
.BR sched_setaffinity (2),
.BR sched_setscheduler (2),
.BR pthread_attr_setaffinity_np (3),
.BR pthread_self (3),
.BR cpuset (7),
.BR pthreads (7)
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Bert Wesarg]

On Fri, Nov 14, 2008 at 16:38, Michael Kerrisk
<mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> [CC += "Paul Jackson" <pj-sJ/iWh9BUns@public.gmane.org>, who might want to Ack the patch below]
>
>>> This might be obvious to all of you, but it wasn't to me... The CPU set used
>>> for the affinity is the intersection of the set passed to
>>> pthread_setaffinity_np() and the set of processors supported by the
>>> kernel...
>>>
>>> That's why your example shall work, even if the system where it runs has
>>> less than 8 processors.
>>
>> It's true.  The page should say something to make this clearer.  I
>> added this text to NOTES
>>
>>       After a call to  pthread_setaffinity_np(3),  the  set  of
>>       CPUs  on which the thread will actually run is the inter-
>>       section of the set specified in the cpuset  argument  and
>>       the set of CPUs actually present on the system.  The sys-
>>       tem may further restrict the set of  CPUs  on  which  the
>>       thread  runs  if  the  "cpuset"  mechanism  described  in
>>       cpuset(7) is  being  used.   These  restrictions  on  the
>>       actual  set  of  CPUs  on  which  the thread will run are
>>       silently imposed by the kernel.
>
> Of course, the sched_setaffinity.2 page also deserves similar text.  I
> made the change below.
>
> Look ok?
Yes.

Thanks.
Bert
>
> Cheers,
>
> Michael
>
> --- a/man2/sched_setaffinity.2
> +++ b/man2/sched_setaffinity.2
>
> @@ -122,7 +122,10 @@ A supplied memory address was invalid.
>  .B EINVAL
>  The affinity bit mask
>  .I mask
> -contains no processors that are physically on the system.
> +contains no processors that are currently physically on the system
> +and permitted to the process according to any restrictions that
> +may be imposed by the "cpuset" mechanism described in
> +.BR cpuset (7).
>  .TP
>  .B EINVAL
>  .RB ( sched_getaffinity ()
> @@ -157,6 +160,19 @@ argument was removed, but was then restored in glibc 2.3.4,
>  with type
>  .SH "CONFORMING TO"
>  These system calls are Linux-specific.
>  .SH "NOTES"
> +After a call to
> +.BR sched_setaffinity (),
> +the set of CPUs on which the process will actually run is
> +the intersection of the set specified in the
> +.I mask
> +argument and the set of CPUs actually present on the system.
> +The system may further restrict the set of CPUs on which the process
> +runs if the "cpuset" mechanism described in
> +.BR cpuset (7)
> +is being used.
> +These restrictions on the actual set of CPUs on which the process
> +will run are silently imposed by the kernel.
> +
>  .BR sched_setscheduler (2)
>  has a description of the Linux scheduling scheme.
>  .PP
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Delivery Status Notification (Failure)

[Bert Wesarg]

On Fri, Nov 14, 2008 at 16:45, Michael Kerrisk
<mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> Bother!  Mail to Paul Jackson bounced from the last address I had for
> him.  Anyway know an up-to-date address?
Hmm, the last message in linux@vger is from Sep 11.

Bert
>
> On Fri, Nov 14, 2008 at 10:38 AM, Mail Delivery Subsystem
> <mailer-daemon-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>> This is an automatically generated Delivery Status Notification
>>
>> Delivery to the following recipient failed permanently:
>>
>>     pj-sJ/iWh9BUns@public.gmane.org
>>
>> Technical details of permanent failure:
>> Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 cuda_nsu 5.7.1 <pj-sJ/iWh9BUns@public.gmane.org>: Recipient address rejected: THIS USER IS NO LONGER WITH SGI. CONTACT help-sJ/iWh9BUns@public.gmane.org IF YOU NEED INFO. (state 14).
>>
>>   ----- Original message -----
>>
>> Received: by 10.180.222.1 with SMTP id u1mr289004bkg.62.1226677136648;
>>        Fri, 14 Nov 2008 07:38:56 -0800 (PST)
>> Received: by 10.181.33.19 with HTTP; Fri, 14 Nov 2008 07:38:56 -0800 (PST)
>> Message-ID: <cfd18e0f0811140738i33f2c671kc99bbb7750f2fa44-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> Date: Fri, 14 Nov 2008 10:38:56 -0500
>> From: "Michael Kerrisk" <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>> Reply-To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> To: "Loic Domaigne" <tech-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>, "Paul Jackson" <pj-sJ/iWh9BUns@public.gmane.org>
>> Subject: Re: For review: pthread_setaffinity_np.3
>> Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, josv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
>>        "brian m. carlson" <sandals-spVehEqlxw627WubY2PhZQivdfXVPZ6z@public.gmane.org>,
>>        "Bert Wesarg" <bert.wesarg-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>,
>>        "Stefan Puiu" <stefanpuiuro-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>,
>>        "Karsten Weiss" <K.Weiss-Pt+Xe7GJXK+P2YhJcF5u+nqWYbMAw+HU@public.gmane.org>
>> In-Reply-To: <cfd18e0f0811140704l18e5741fgdbb5a6c52fb8cbe7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=ISO-8859-1
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: inline
>> References: <cfd18e0f0811041447w57dd5de4he68ca780ed963074-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>         <4916133A.8060209-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>
>>         <cfd18e0f0811140704l18e5741fgdbb5a6c52fb8cbe7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>
>> [CC += "Paul Jackson" <pj-sJ/iWh9BUns@public.gmane.org>, who might want to Ack the patch below]
>>
>>>> This might be obvious to all of you, but it wasn't to me... The CPU set used
>>>> for the affinity is the intersection of the set passed to
>>>> pthread_setaffinity_np() and the set of processors supported by the
>>>> kernel...
>>>>
>>>> That's why your example shall work, even if the system where it runs has
>>>> less than 8 processors.
>>>
>>
>>   ----- Message truncated -----
>>
>>
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
> man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
> Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Delivery Status Notification (Failure)

[Michael Kerrisk]

On Fri, Nov 14, 2008 at 10:56 AM, Bert Wesarg
<bert.wesarg-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> On Fri, Nov 14, 2008 at 16:45, Michael Kerrisk
> <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>> Bother!  Mail to Paul Jackson bounced from the last address I had for
>> him.  Anyway know an up-to-date address?
> Hmm, the last message in linux@vger is from Sep 11.

Yep.  But Paul Jackson <pj-sJ/iWh9BUns@public.gmane.org> isn't working.

(And nothing from Paul since 11 Sep is a longish silence from him.)

>
> Bert
>>
>> On Fri, Nov 14, 2008 at 10:38 AM, Mail Delivery Subsystem
>> <mailer-daemon-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>>> This is an automatically generated Delivery Status Notification
>>>
>>> Delivery to the following recipient failed permanently:
>>>
>>>     pj-sJ/iWh9BUns@public.gmane.org
>>>
>>> Technical details of permanent failure:
>>> Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 cuda_nsu 5.7.1 <pj-sJ/iWh9BUns@public.gmane.org>: Recipient address rejected: THIS USER IS NO LONGER WITH SGI. CONTACT help-sJ/iWh9BUns@public.gmane.org IF YOU NEED INFO. (state 14).
>>>
>>>   ----- Original message -----
>>>
>>> Received: by 10.180.222.1 with SMTP id u1mr289004bkg.62.1226677136648;
>>>        Fri, 14 Nov 2008 07:38:56 -0800 (PST)
>>> Received: by 10.181.33.19 with HTTP; Fri, 14 Nov 2008 07:38:56 -0800 (PST)
>>> Message-ID: <cfd18e0f0811140738i33f2c671kc99bbb7750f2fa44-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>> Date: Fri, 14 Nov 2008 10:38:56 -0500
>>> From: "Michael Kerrisk" <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>> Reply-To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>>> To: "Loic Domaigne" <tech-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>, "Paul Jackson" <pj-sJ/iWh9BUns@public.gmane.org>
>>> Subject: Re: For review: pthread_setaffinity_np.3
>>> Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, josv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
>>>        "brian m. carlson" <sandals-spVehEqlxw627WubY2PhZQivdfXVPZ6z@public.gmane.org>,
>>>        "Bert Wesarg" <bert.wesarg-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>,
>>>        "Stefan Puiu" <stefanpuiuro-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>,
>>>        "Karsten Weiss" <K.Weiss-Pt+Xe7GJXK+P2YhJcF5u+nqWYbMAw+HU@public.gmane.org>
>>> In-Reply-To: <cfd18e0f0811140704l18e5741fgdbb5a6c52fb8cbe7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>> MIME-Version: 1.0
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> Content-Transfer-Encoding: 7bit
>>> Content-Disposition: inline
>>> References: <cfd18e0f0811041447w57dd5de4he68ca780ed963074-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>>         <4916133A.8060209-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>
>>>         <cfd18e0f0811140704l18e5741fgdbb5a6c52fb8cbe7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>>
>>> [CC += "Paul Jackson" <pj-sJ/iWh9BUns@public.gmane.org>, who might want to Ack the patch below]
>>>
>>>>> This might be obvious to all of you, but it wasn't to me... The CPU set used
>>>>> for the affinity is the intersection of the set passed to
>>>>> pthread_setaffinity_np() and the set of processors supported by the
>>>>> kernel...
>>>>>
>>>>> That's why your example shall work, even if the system where it runs has
>>>>> less than 8 processors.
>>>>
>>>
>>>   ----- Message truncated -----
>>>
>>>
>>
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
>> man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
>> Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
>>
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Michael Kerrisk]

On Fri, Nov 14, 2008 at 10:52 AM, Bert Wesarg
<bert.wesarg-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> On Fri, Nov 14, 2008 at 16:38, Michael Kerrisk
> <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>> [CC += "Paul Jackson" <pj-sJ/iWh9BUns@public.gmane.org>, who might want to Ack the patch below]
>>
>>>> This might be obvious to all of you, but it wasn't to me... The CPU set used
>>>> for the affinity is the intersection of the set passed to
>>>> pthread_setaffinity_np() and the set of processors supported by the
>>>> kernel...
>>>>
>>>> That's why your example shall work, even if the system where it runs has
>>>> less than 8 processors.
>>>
>>> It's true.  The page should say something to make this clearer.  I
>>> added this text to NOTES
>>>
>>>       After a call to  pthread_setaffinity_np(3),  the  set  of
>>>       CPUs  on which the thread will actually run is the inter-
>>>       section of the set specified in the cpuset  argument  and
>>>       the set of CPUs actually present on the system.  The sys-
>>>       tem may further restrict the set of  CPUs  on  which  the
>>>       thread  runs  if  the  "cpuset"  mechanism  described  in
>>>       cpuset(7) is  being  used.   These  restrictions  on  the
>>>       actual  set  of  CPUs  on  which  the thread will run are
>>>       silently imposed by the kernel.
>>
>> Of course, the sched_setaffinity.2 page also deserves similar text.  I
>> made the change below.
>>
>> Look ok?
> Yes.

Thanks.

-mtk

>> --- a/man2/sched_setaffinity.2
>> +++ b/man2/sched_setaffinity.2
>>
>> @@ -122,7 +122,10 @@ A supplied memory address was invalid.
>>  .B EINVAL
>>  The affinity bit mask
>>  .I mask
>> -contains no processors that are physically on the system.
>> +contains no processors that are currently physically on the system
>> +and permitted to the process according to any restrictions that
>> +may be imposed by the "cpuset" mechanism described in
>> +.BR cpuset (7).
>>  .TP
>>  .B EINVAL
>>  .RB ( sched_getaffinity ()
>> @@ -157,6 +160,19 @@ argument was removed, but was then restored in glibc 2.3.4,
>>  with type
>>  .SH "CONFORMING TO"
>>  These system calls are Linux-specific.
>>  .SH "NOTES"
>> +After a call to
>> +.BR sched_setaffinity (),
>> +the set of CPUs on which the process will actually run is
>> +the intersection of the set specified in the
>> +.I mask
>> +argument and the set of CPUs actually present on the system.
>> +The system may further restrict the set of CPUs on which the process
>> +runs if the "cpuset" mechanism described in
>> +.BR cpuset (7)
>> +is being used.
>> +These restrictions on the actual set of CPUs on which the process
>> +will run are silently imposed by the kernel.
>> +
>>  .BR sched_setscheduler (2)
>>  has a description of the Linux scheduling scheme.
>>  .PP
>>
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Delivery Status Notification (Failure)

[Christoph Lameter]

Will try to figure out whats going on. Give me a couple of hours.


--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Delivery Status Notification (Failure)

[Christoph Lameter]

It seems that Paul retired.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Delivery Status Notification (Failure)

[Michael Kerrisk]

On Fri, Nov 14, 2008 at 11:39 AM, Christoph Lameter
<cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> It seems that Paul retired.

Thanks for the info Christoph.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Delivery Status Notification (Failure)

[David Rientjes]

On Fri, 14 Nov 2008, Michael Kerrisk wrote:

> On Fri, Nov 14, 2008 at 11:39 AM, Christoph Lameter
> <cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> > It seems that Paul retired.
> 
> Thanks for the info Christoph.
> 

commit c222817f6add85197790e0071f6e511eff14ba25
Author: Paul Jackson <pj-sJ/iWh9BUns@public.gmane.org>
Date:   Fri Oct 3 15:23:42 2008 -0700

    cpusets: remove pj from cpuset maintainers
    
    Remove myself from the kernel MAINTAINERS file for cpusets.  I am leaving
    SGI and probably will not be active in Linux kernel work.  I can be
    reached at <pj-Jdbf3xiKgS8@public.gmane.org>.  Contact Derek Fults <dfults-sJ/iWh9BUns@public.gmane.org> for future
    SGI+cpuset related issues.  I'm off to the next chapter of this good life.
    
    Signed-off-by: Paul Jackson <pj-sJ/iWh9BUns@public.gmane.org>
    Cc: Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
    Cc: Derek Fults <dfults-sJ/iWh9BUns@public.gmane.org>
    Cc: John Hesterberg <jh-sJ/iWh9BUns@public.gmane.org>
    Cc: Paul Jackson <pj-Jdbf3xiKgS8@public.gmane.org>
    Signed-off-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
    Signed-off-by: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Loic Domaigne]

Hi Michael!

Looks good to me. I have only one minor comment left, regarding EINVAL 
for pthread_setaffinity_np():

> .TP
> .BR EINVAL
> .RB ( pthread_setaffinity_np ())
> .I cpuset
> specified a CPU that was outside the set supported by the kernel.
> (The kernel configuration option
> .BR CONFIG_NR_CPUS
> defines the range of the set supported by the kernel data type
> .\" cpumask_t
> used to represent CPU sets.)
> .\" The raw sched_getaffinity() system call returns the size (in bytes)
> .\" of the cpumask_t type.

In the light of Bert's comment, it seems that the Linux kernel folks 
wants to make the cpumask_t dynamic. So CONFIG_NR_CPUS might become 
obsolete in the future...

But for now, your explanation is fine.

Cheers,
Loïc.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: pthread_setaffinity_np.3

[Michael Kerrisk]

On Sat, Nov 15, 2008 at 2:41 PM, Loic Domaigne <tech-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org> wrote:
> Hi Michael!
>
> Looks good to me. I have only one minor comment left, regarding EINVAL for
> pthread_setaffinity_np():
>
>> .TP
>> .BR EINVAL
>> .RB ( pthread_setaffinity_np ())
>> .I cpuset
>> specified a CPU that was outside the set supported by the kernel.
>> (The kernel configuration option
>> .BR CONFIG_NR_CPUS
>> defines the range of the set supported by the kernel data type
>> .\" cpumask_t
>> used to represent CPU sets.)
>> .\" The raw sched_getaffinity() system call returns the size (in bytes)
>> .\" of the cpumask_t type.
>
> In the light of Bert's comment, it seems that the Linux kernel folks wants
> to make the cpumask_t dynamic. So CONFIG_NR_CPUS might become obsolete in
> the future...
>
> But for now, your explanation is fine.

Okay.  Thanks for the info Loic.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html