All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tolga Dalman <tolga.dalman-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Carlos O'Donell <carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org>
Cc: KOSAKI Motohiro
	<kosaki.motohiro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	libc-alpha <libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org>,
	linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
Date: Mon, 29 Jun 2015 23:40:37 +0200	[thread overview]
Message-ID: <5591BB55.5080605@googlemail.com> (raw)
In-Reply-To: <558DB0A0.2040707-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Michael,

given the approach is accepted by Carlos and Roland, I have
some minor textual suggestions for the patch itself.

On 06/26/2015 10:05 PM, Michael Kerrisk (man-pages) wrote:
> --- a/man2/sched_setaffinity.2
> +++ b/man2/sched_setaffinity.2
> @@ -223,6 +223,47 @@ system call returns the size (in bytes) of the
>  .I cpumask_t
>  data type that is used internally by the kernel to
>  represent the CPU set bit mask.
> +.SS Handling systems with more than 1024 CPUs

What if the system has exactly 1024 CPUs ?
Suggestion: systems with 1024 or more CPUs

> +The
> +.I cpu_set_t
> +data type used by glibc has a fixed size of 128 bytes,
> +meaning that the maximum CPU number that can be represented is 1023.
> +.\" FIXME . See https://sourceware.org/bugzilla/show_bug.cgi?id=15630
> +.\" and https://sourceware.org/ml/libc-alpha/2013-07/msg00288.html

No objection, although I have never really noticed external references
in man-pages (esp. web refs). Shouldn't these be generally avoided ?
(and yes, I have noticed the FIXME)

> +If the system has more than 1024 CPUs, then calls of the form:

1024 or more CPUs.

> +
> +    sched_getaffinity(pid, sizeof(cpu_set_t), &mask);
> +
> +will fail with the error
> +.BR EINVAL ,
> +the error produced by the underlying system call for the case where the
> +.I mask
> +size specified in
> +.I cpusetsize
> +is smaller than the size of the affinity mask used by the kernel.
> +.PP
> +The underlying system calls (which represent CPU masks as bit masks of type
> +.IR "unsigned long\ *" )
> +impose no restriction on the size of the mask.
> +To handle systems with more than 1024 CPUs, one must dynamically allocate the
> +.I mask
> +argument using
> +.BR CPU_ALLOC (3)

I would rewrite the sentence to avoid "one must".

> +and manipulate the mask using the "_S" macros described in

and manipulate the macros ending with "_S" as described in

> +.BR CPU_ALLOC (3).
> +Using an allocation based on the number of online CPUs:
> +
> +    cpu_set_t *mask = CPU_ALLOC(CPU_ALLOC_SIZE(
> +                                sysconf(_SC_NPROCESSORS_CONF)));
> +
> +is probably sufficient, although the value returned by the
> +.BR sysconf ()
> +call can in theory change during the lifetime of the process.
> +Alternatively, one can obtain a value that is guaranteed to be stable for

Like above, I would replace "one can obtain a value" by "a value can be obtained".

> +the lifetime of the process by proby for the size of the required mask using

s/proby/probing/.

> +.BR sched_getaffinity ()
> +calls with increasing mask sizes until the call does not fail with the error
> +.BR EINVAL .

I would replace "until the call does not fail with error ..." by "while the call succeeds".

Also, the sentence too long, IMHO.

Best regards
Tolga Dalman



--
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

  parent reply	other threads:[~2015-06-29 21:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <51E42BFE.7000301@redhat.com>
     [not found] ` <51E4A0BB.2070802@gmail.com>
     [not found]   ` <51E4A123.9070001@gmail.com>
     [not found]     ` <51E6F3ED.8000502@redhat.com>
     [not found]       ` <51E6F956.5050902@gmail.com>
     [not found]         ` <51E714DE.6060802@redhat.com>
     [not found]           ` <CAHGf_=oZW3kNA3V-9u+BZNs3tL3JKCsO2a0Q6f0iJzo=N4Wb8w@mail.gmail.com>
     [not found]             ` <51E7B205.3060905@redhat.com>
     [not found]               ` <20130722214335.D9AFF2C06F@topped-with-meat.com>
     [not found]                 ` <51EDB378.8070301@redhat.com>
     [not found]                   ` <51EDB378.8070301-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-26 14:28                     ` What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t? Michael Kerrisk (man-pages)
     [not found]                       ` <558D6171.1060901-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-06-26 20:05                         ` Michael Kerrisk (man-pages)
     [not found]                           ` <558DB0A0.2040707-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-06-29 21:40                             ` Tolga Dalman [this message]
     [not found]                               ` <5591BB55.5080605-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2015-07-21 15:03                                 ` Michael Kerrisk (man-pages)
2015-07-01 12:37                           ` Florian Weimer
     [not found]                             ` <5593DF14.2060804-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-07-21 15:03                               ` Michael Kerrisk (man-pages)
     [not found]                                 ` <55AE5F33.3080105-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-07-22 16:02                                   ` Florian Weimer
     [not found]                                     ` <55AFBE87.1040006-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-07-22 16:43                                       ` Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5591BB55.5080605@googlemail.com \
    --to=tolga.dalman-gm/ye1e23mwn+bqq9rbeug@public.gmane.org \
    --cc=carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=kosaki.motohiro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.