[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Scheduling in domain


  • To: "Ashish Puri" <ashish.xen@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Mon, 25 Sep 2006 13:32:29 +0200
  • Delivery-date: Mon, 25 Sep 2006 04:33:18 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acbgk2WI4ma6OewpQDiOxRDZSetG1AAACjpA
  • Thread-topic: [Xen-devel] Scheduling in domain

 


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.