On 05/28/2011 09:32 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> 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.
But if we indexed by the TID then we wouldnt need any scheduler bindings at all - this is the simpler approach.
Yes, and it maps 1:1 to the kernel implementation (cpu = task).
> What's needed are explicit notifications about grace periods. For > the vcpu threads, calling KVM_VCPU_RUN seems like a good point. > For I/O threads, completion of processing of an event is also a > good point. Grace period notifications are needed too, obviously.
I'd think they're sufficient, no? Is something else needed? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
