On Sat, May 28, 2011 at 05:24:08PM +0200, Ingo Molnar wrote: > > * Sasha Levin <levinsasha928@xxxxxxxxx> wrote: > > > So the basic plan here is to allocate a futex(?) for each VCPU > > thread, and have the writer thread lock all futexes when it needs > > to write? > > > > If we assume we only have one writer thread, it can stay pretty > > simple. > > We can use an even simpler and more scalable method: > > - writers can 'stop' all other threads, by sending them a > threadpool signal and waiting for each thread to have completed > processing their current work and notifying the writer back that > they have stopped running. > > This means that the read-side lock is _zero instructions_, basically > just a barrier() to make sure the compiler does not move instructions > across threadpool functions (it wont). > > This method requires that we know about every worker thread - i.e. > no-one does a stray pthread_create() and uses data structures from > there. It also requires that each worker thread can 'stop' within a > reasonable amount of time. Yep, this should work -- similar to use of stop_machine() in the kernel, but without the need for worker threads to disable preemption because there is no need for separate "cpu" and "task" concepts like there is in the kernel. The updates are quite heavyweight and they must block all readers, but if updates are infrequent enough, this clearly won't be a problem. Simpler than porting TREE_RCU to userspace as well, though I might do that some time just for grins. Thanx, Paul -- 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
