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
|