________________________________
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ashish Puri
Sent: 25 September 2006 12:11
To: xen-devel@lists.xensource.com; xen-users@lists.xensource.com
Subject: [Xen-devel] Scheduling in domain
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@lists.xensource.com
http://lists.xensource.com/xen-devel