lkml.org 
[lkml]   [2008]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2008-07-02 21:59    [W:0.052 / U:4.012 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site