linux-kernel - Re: getcpu(2) man page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 02 Jul 2008 21:57:20 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Michael Kerrisk <mtk.manpages@...glemail.com>
CC:	lkml <linux-kernel@...r.kernel.org>, linux-man@...r.kernel.org
Subject: Re: getcpu(2) man page

Michael Kerrisk wrote:

> .\" FIXME(ak) If the following formulation is correct, I think it would
> .\" be better to substitute it instead of the next sentence:
> .\"     The information placed in \fIcpu\fP is only guaranteed to be
> .\"     current at the time of the call: ...

At least sched_setaffinity should be still mentioned.
Feel free to rephrase it if you think it's better in some other way.

> .\" FIXME(ak) In the following, what precisely do you mean by "advisory"?
> .\" It is not really clear to me whether you mean the information
> .\" may not be "true", or whether you are just reiterating the point that
> .\" the CPU/node might already have changed by the time the call returns.

It's reiterating the point, but in general the caller has to consider
it advisory as a hint only because it cannot rely on it 100% (unless it set the affinity)

> .\" FIXME(ak) what does the phrase "but might query the current state
> .\" only during a short implementation specific interval" mean?
> it will be faster, but might query the current state only during
> a short implementation specific interval.

Originally the cache had a time stamp and then would only get the CPU
information once each jiffie. That works well because the CPU affinity
is typically hold long enough.

Unfortunately someone who didn't understand the design and didn't think
it through took that out  so currently applications have to reimplement that
mechanism in a usually inferior and slower way (querying timers is much slower in
general user space) or do "endless caches" which are also bad


-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/