[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Questions regarding Xen Credit Scheduler
Hi George, Thanks for your reply. I am in the process of fixing some of these issues. So this is what I have in mind: 1. __runq_insert: Insert according to credit as well as priority. Current code just looks at the priority, which is very coarse. 2. __runq_tickle: Tickle the CPU even if the new VCPU has same priority but higher amount of credits left. Current code just looks at the priority. 3. csched_runq_sort: Sort according to credit. 4. csched_acct: If credit of a VCPU crosses 300, then set it to 300, not 0. I am still not sure why the VCPU is being marked as inactive? Can't I just update the credit and let it be active? 5. csched_schedule: Always call csched_load_balance. In the csched_load_balance and csched_runq_steal functions, change the logic to grab a VCPU with higher credit. Current code just works on priority. Do you think, these ideas make sense? Am I missing out on something? > Regarding specific things: > > One thing you didn't catch is that credits before 4.0 are debited > probabilistically, a full 10ms at a time, by the very timer tick that > moves a vcpu from "inactive" to "active"; so when you make the switch > from "active" to "inactive", you don't start out at 0, but at -10ms. Yes, I noticed this; point 4 above tries to address this. As I mentioned above, I am not sure why it is being marked inactive in first place? > It turns out that's not only bad for latency-sensitive processes, but > it's also a security bug; so there's a patch in 4.0 (not sure whether > it's been backported to 3.4) to do accurate accounting based on RDTSC > reads instead of probabilistic-based accounting based on timer ticks. Yes, I have seen Xen 4.0 code; it does deterministic accounting by recording the amount of time spent on the CPU by a VCPU. > So the answer to #3 is: > * The "accurate credit" patch is in 4.0, maybe 3.4. That should help > somewhat. > * I have a patch that will change the "reset condition"; I'm > considering submitting it. I'd appreciate testing / feedback. (I'll > send this in a separate e-mail.) Please do send this. > * There is no patch yet that will fix the sort-by-priority, but it > should be simple and straightforward to implement. I'll support > putting it in once I'm reasonably convinced that it helps and doesn't > hurt too much. If you were to help out with the implementation and > testing, that will happen a lot faster. :--) I am trying to implement the ideas I mentioned above. You feedback would be very helpful. Thanks, -Gaurav _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |