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

RE: [Xen-devel] Scheduling in domain


  • To: "Ashish Puri" <ashish.xen@xxxxxxxxx>
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Mon, 25 Sep 2006 14:29:58 +0200
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 25 Sep 2006 05:30:44 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbgnLO4fWuNzITXQ/iIca6VJyIgBgAADwBw
  • Thread-topic: [Xen-devel] Scheduling in domain

 


From: Ashish Puri [mailto:ashish.xen@xxxxxxxxx]
Sent: 25 September 2006 13:18
To: Petersson, Mats
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Scheduling in domain

On 9/25/06, Petersson, Mats <Mats.Petersson@xxxxxxx> wrote:
 
Is there any particular use-case where you're seeing this as a problem, or is this a purely theoretical question? 
 
 
Thanks Mats. I was browising throught he code and documents and felt that scheduling in domain can go for the toss if domain is not aware of the virtual time.  
 
As far as I'm aware, Linux and Windows doesn't use time directly in the scheduling of processes/tasks/threads [nor does any other OS that I know enough about to at least have a vague idea of how it work]. The timer-tick is used to keep track of time-slots, so if many timer-ticks are inserted with short intervals, you may find that some process gets a shorter time-slice than expected, but I don't think it's going to be dramatically different than for example in a heavily loaded system where interrupts could steal a large amount of CPU-time.
 
It is worth bearing in mind that any virtualized environment will behave slightly differently than the bare-metal corresponding version, and one of the well-documented side-effects of virtualiztion is the fact that time "may jump forward" [in less than technical terms!]. But the same can happen in a bare-metal system: what if you have a process running and somewhere in the system there is a sleeping process of EXTREMELY HIGH PRIORITY, which gets woken by some external event (network packet received, time-out of some sort, etc): that will cause the current process to be descheduled - there may be any amount of time before it's scheduled again. But certainly, Xen is not a real-time system in any sense other than "It's not a batch-job operating system" - any sort of closer to "strict realtime" is definitely NOT for Xen - there is no strict priority between domains...
 
Again, I appologize for lack of knowledge of Xen 2.0, so I can't say where the domain_time has gone - maybe it's related to the fact that each domain can have independent time nowadays - but that would only be a very simple guess..
 
--
Mats
 
I am also interested in knowing that why the domain_time has been removed in 3.0??
 
 
Thanks,
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®.