On 05/29/2011 03:37 PM, Ingo Molnar wrote:
> >
> > It's not transparent at all if you index RCU data structures by
> > the current CPU index, which the kernel implementation does.
>
> But that's completely broken for userspace. The "current cpu
> index" doesn't even exist, since you can't disable preemption.
It does exist, if the signal handler notification of a migration is
instantaneous (which it is).
Something like rcu_preempt_qs(), which expects to be called with
interrupts disabled, cannot be made to work.
I don't understand how you expect per_cpu to work in userspace. As soon
as you calculate the per-cpu address, it can be invalidated. It doesn't
help that you get a signal; you've already calculated the address.
Also, in the kernel, using per-cpu data implies mutual exclusion (since
you've disabled preemption). That doesn't apply to userspace.
> > Doing that has the advantage of being much more cache-compressed
> > than the TID index,
>
> If you have more tasks than cpus; which isn't a given.
Sure there are special cases but in general there can be many more
tasks (threads) than CPUs ;-)
Sure; that was just a side note.
Note that for server virtualization you usually have less tasks (in a
process, not globally) than host cpus.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
