Hello,
Jeff Squyres wrote:
> On Apr 22, 2007, at 11:30 AM, Bert Wesarg wrote:
>
>> Hmm, than its possibly not too late to think about an API addition
>> of an
>> interface to the linux getcpu[1] syscall. This would be handy, I even
>> can't find it in the current glibc code base.
>
> Can you describe what this function does?
Sure:
/* Fast way to get current CPU and node.
This helps to do per node and per CPU caches in user space.
The result is not guaranteed without CPU affinity, but usually
works out because the scheduler tries to keep a thread on the same
CPU. */
long sys_getcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *tcache);
The 'struct getcpu_cache' is opaque to user space and is defined in
<linux/getcpu.h>. The call is task specific, so you get the cpu/node info
for the calling thread. I read in the discussion for this syscall, that
user space should simply declare this variable as a per thread variable
with the __thread attribute. I can't try it out, my current dual socket
system have a very old kernel (2.6.14) and my note book is single. Maybe I
find a machine at the university where I can try it. At least version
2.6.19 is needed.
>
>> And one think that come up to me last night is cpu hotplugging!
>> For plpa-taskset this is not important, but for long running tasks
>> this
>> may become important. So the cache needs some refreshment when a
>> cpu goes
>> online/offline.
>
> Mm... good point. How does one harness hotplugging? Is there a way
> to know that information has changed such that we need to refresh the
> cache?
Yeah, I've already dig in this direction, the only thing I have found is a
udev notification type, its described in the last section of
Documentation/cpu-hotplug.txt. And the only way to get this to an
application seems to be the way over dbus. But I'm not even sure dbus
handle these events.
Bert
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}