Hello, (Please CC me, thank you)
Ulrich Drepper wrote: > The attached test program fails on a dual core (and probably SMP) > machine on x86-64. Depending on where the thread starts, in one of the > iterations the sched_setffinity() call succeeds but then sched_getcpu() > fails to report the correct CPU. > > In set_cpus_allowed migrate_task() is called if the new CPU set does not > include the current CPU. I hope that migrate_task() also works for > p==current. > > This leaves the x86-64 vgetcpu() implementation as the weak point. Is > the caching causing problems? Should migrate_task() make sure the cache > is reset? > > You need a very recent glibc to compile (glibc-2.5.90-22 in rawhide). > If this is not available replace the sched_getcpu() call. But make sure > you pass a pointer to a cache. > > A question not related to this problem, but may I ask why the libc don't use[1] the linux/getcpu.h header to get the opaque struct vgetcpu_cache? Thank You Bert Wesarg [1]: http://sourceware.org/ml/glibc-cvs/2007-q2/msg00098.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
