On Wed, 28 Jan 2015 10:55:53 -0800 "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > Then your only hope is to prevent the host (and other guests) from > preempting the real-time guest. Right! I think there's a miscommunication here. Basically what is needed is to run the RT guest on a CPU by itself. We can all agree on that. That guest runs at a high priority where nothing should preempt it. We should enable NO_HZ_FULL, and move as much off of that CPU as possible (including rcu callbacks). I'm not sure if the code does this or not, but I believe it does. When we enter the guest, the host should be in an RCU quiescent state, where RCU will ignore the CPU that is running the guest. Remember, we are only talking about interactions of the host, not the workings of the guest. Once this isolation happens, then the guest should be running in a state that it could handle RT reaction times for its own processes (if the guest OS supports it). The guest shouldn't be preempted by anything unless it does something that requires a service (interacting with the network or other baremetal device), then it will need to do the same things that any RT task must do. I think all this is feasible. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
