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