> >> Please dont even think about using yield for this though - Oops. I'm glad I waited to get some benchmark results before submitting that version. > >> A gradual and linear back-off from the current timeline is > >> more of a fair negotiation process between vcpus and > >> results in more or less > >> sane (and fair) scheduling, and no unnecessary looping. > >> > >> You could even do an exponential backoff up to a limit of > >> 1-10 msecs or so, starting at 100 usecs. > > > > Good idea, it eliminates another variable to be tuned. > > It could be made fully self-tuning, if the filter threshold can be > tuned fast enough. (an MSR write? A VM context field update?) VMCB field update. So the suggestion is to add a function similar to set_task_cpu() that increases the vmruntime with an exponential backoff? Is that sufficient to cause a new VCPU to step in? I'm obviously not very familiar with the scheduler code. > I.e. the 3000 cycles value itself could be eliminated as well. (with > just a common-sense max of say 100,000 cycles enforced) I don't understand what you're saying here. There needs to be some value in the pause filter counter to trigger the intercept. -Mark Langsdorf Operating System Research Center AMD -- 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
