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
|
Home