Hi,
I have few doubts regarding the process scheduling in the domains.
1. In Xen 3.0 is guest aware of virtual time?? I see in the Xen 2.0 code
that domain_time is present in the shared info pages. However i could not
find similar field in the Xen 3.0 code.
I'm not ignoring this question, but since I've only worked on 3.0 -
and not really dealt much with how time is working, I can't
really comment on this...
2. If not, how is domain expected to do the "fair"
scheduling/accounting for the processes running in the domain?? If vcpu is
descheduled and later when it is rescheduled i see in the code that it will
simply call do_timer() multiple times, in guest, to account for the
"missing time" and update the jiffies multiple time. Also, the
scduler_tick() is called repetedly. My question is: isn't this wrong, in the
sense that process might not have run for its allocated time??? Am i missing
something??
The scheduling WITHIN domains is handled by the guest OS (Linux or
Windows for instance), and the calling of timer is to adjust the system time to
match the "real" time. scheduler_tick() sounds to me (I haven't looked at the
code) to be the part
that informs the scheduler that "time has passed".
Unfortunately, it's impossible to do anything much better without
other severe sacrifices - if nothing else, simply because Xen hypervisor hasn't
got any visibility of the individual processes running WITHIN a domain.
However, a domain will only be "not run" under three
circumstances:
1. It's not needing run at the time - in which case it's no
problem.
2. Some interrupt causes the current domain to be descheduled due
to it's timeslice is out - this is certainly a cause for some concern, but to be
fair, everyone that is running heavy-cpu-loads should be interrupted to let
others run at some point. [Note, timeslices only mean anything if there's any
competition for CPU-time. One domain can use 100% of a CPU as long as no other
domain needs CPU-time].
3. Some other process of higher priority became viable to run.
This realisticly, with the credit scheduler, is only another case of #2 above,
since there is only "two" priorities in the system - either low or high. High
priority is achieved by NOT USING MUCH CPU, so it's only fair that those
processes that don't tax the system CPU-wise are given a "better than average
chance" to run.
If you are basing how much CPU-time a process is getting on
internal calculations within the guest-OS, then I'd say that this would not
reflect the "truth" at all times - partciularly not if there are several
CPU-intensive VM's running on the same CPU.
It would be very interesting to hear if someone has a
not-too-intrusive suggestion for how to solve this. As far as my limited
understanding, the only way to really solve this would be to move the process
accounting from the guest into Xen, which would have two side-effects: Xen would
have to understand task-scheduling within the guest and any
guest-task-time-accounting would gain a somewhat higher penalty in the form of a
hypercall instead of (generally) simple update of a local variable. I'm sure
someone else knows more about this subject, and I'd be happy to hear suggestions
and comments, but I'm also pretty sure that the above suggestion is both hard to
implement (because Xen is supposed to be able to run more than ONE type of OS -
and implementing several scheduling schemes will not make things any easier,
that's for sure).
3. If yes, how it is used to do fair scheduling??
The credit scheduler is pretty good at
fairly distributing CPU-time between the domains. The rest of the
work is up to the guest-OS, which may or may not be
fair.
Is there any particular use-case where you're seeing this as a
problem, or is this a purely theoretical question?
Finally, I think this is definitely a question for Xen-devel, rather than
for Xen-users, since Xen-users is more for about the actual usage of Xen, and
less about "how the internals of Xen works" - which is definitely in the "devel"
field - so I removed the "users" on this reply.
--
Mats
Thanks and Regards,
Ashish.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|