Anthony Liguori wrote: >> >> Yes. The loop was a (perhaps premature) optimization that is now >> totally unnecessary, unless I'm missing something quite large. >> > > It used to be that kvm_eat_signal() selected after consuming as many > signals as possible while only sleeping once. That's why there's a > combination of sleeping and polling. >
Yes. > Now the VCPU threads never select so the whole loop can be simplified > to a single sigtimedwait() that always blocks. > > In reality, I don't think sigtimedwait() is really needed/useful for > VCPUs anymore. We only use it to catch SIG_IPI and we only use > SIG_IPI to break out of sleeping. I don't see any reason why we > couldn't switch over to using a file descriptor for notification (or a > pthread condition). How would you stop a vcpu running in guest mode? > In the very least, we could just select() on nothing and allow SIG_IPI > to break us out of the select. sigtimedwait() (or just sigwait, now) doesn't require the signal to be delivered, so it's faster. If there's nothing to select, why call select()? -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
