* Avi Kivity <[email protected]> wrote:
> On 05/29/2011 10:35 AM, Ingo Molnar wrote:
> >* Avi Kivity<[email protected]> wrote:
> >
> >> On 05/28/2011 09:32 PM, Ingo Molnar wrote:
> >> >* Avi Kivity<[email protected]> wrote:
> >> >
> >> >> > So if you set a notification signal via fcntl(F_SETOWN) on the
> >> >> > scheduler context switch event fd, the user-space RCU code will
> >> >> > get a signal on every context switch.
> >> >>
> >> >> Context switches are completely uninteresting for userspace rcu:
> >> >>
> >> >> rcu_read_lock();
> >> >> ---> context switch
> >> >>
> >> >> have we learned anything from that? no. User code is always
> >> >> preemptible and migratable. If rcu_read_lock() prevented migration
> >> >> somehow, then we'd know that a context switch means we've started a
> >> >> grace period for this thread. But it doesn't, so we don't.
> >> >
> >> >Well, in the next mail i mentioned that we can do migration events as
> >> >well, which would be useful: instead of having to keep track of
> >> >nr_tasks RCU grace periods we could simplify it down to nr_cpus.
> >>
> >> I don't see how a migration event helps. It is completely
> >> transparent from the task's point of view.
> >
> > 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).
> > 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 ;-)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
