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

[Xen-devel] Re: Question about the Xen Scheduler


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Girish V" <girish.xen@xxxxxxxxx>
  • Date: Tue, 9 Sep 2008 14:26:24 -0400
  • Delivery-date: Tue, 09 Sep 2008 11:26:47 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tjWfanuSEiT3tIvsWQl6rrgv63wTwSPMQ5v023Gcnzys+rRVHO0vGSARV6zvHntLvs wCnnh9vQporwRMIU7AmtEEiYN2K9qhKCVh0VHomBR3/VNi1CPqxvF6vaC7eeqcYskg4V +IPuQGa37C/JgdtxQ0PUYsGX0XXTrkW+Zi4GI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

I realized that the reason domU was not being scheduled was because I
had not set the scheduling properly. When domU is created (on Xen
3.0.2) the schedule for the domU is "best effort" i.e. no cpu time
slice is gauranteed to it, but if any cpu time is available, it may be
used for the domU.
xm sched-sedf prints out
Name                              ID          Period(ms)
Slice(ms)          Lat(ms)          Extra          Weight
Domain-0                         0               20.0
  15.0                  0.0               1                  0
user-domain                     3              100.0
  0.0                  0.0               1                  0

Changing this to set equal time slices in a given period for both the
dom0 and domU fixed the issue.

Thanks.

On Tue, Sep 2, 2008 at 1:32 PM, Girish V <girish.xen@xxxxxxxxx> wrote:
> Hello,
> I am trying to understand the behavior of the Xen scheduler. I am
> using Xen 3.0.2 on a 1 CPU machine and I have the default scheduler
> (which I believe is the credit scheduler - and I have not explicitly
> set any weights/caps for the domains).
>
> I have added printk's to the scheduler function (__enter_scheduler() )
> just above the context_switch statement to indicate which domain is
> getting de-scheduled and which domain is getting scheduled.
>
>
> After booting dom0, I have created a dom5 (using a disk image and the
> same unified kernel that is used for booting the dom0).
>
> I do the following experiments.
>
> 1) First I boot up the dom0. No tasks are running on this domain. I
> look at the printk messages - I see that the context switch happens
> between dom0 and domain -1. From reading the mailing lists, I see that
> -1 is the "idle" domain. (Is this an analogue of the idle process
> pid=0 in Linux?) Also I am assuming that this idle domain does not use
> a memory space (ie.) when there is a context switch between dom0 and
> idle domain there is no re-writing of cr3 and hence no tlb flushing
> etc - is this right?
>
> 2) Then I run a spec CPU workload (gzip which uses almost 100% of the
> CPU) on dom0. Looking at the printks, I still see that domain
> switching occurs between dom0 and idle domain. If the dom0 has need of
> the cpu in the next scheduling timeslot and no-one is competing for
> the cpu (both of which are satisfied in the described case) shouldn't
> the dom0 itself be scheduled every time. Why does the idle domain get
> scheduled?
>
> 3) I kill the spec workload on dom0 and boot up a dom4 with the same
> kernel used for dom0 and a disk image as hda. Once the dom4 is
> created, I run gzip on dom4 and no task on dom0. Looking at the
> printks I see that there are dom switches from 0->4 and 4->0. I also
> observe that 0->idle domain and 4->idle domain and idle domain->0/4
> switches also happen.
>
> 4) Then I run a gzip on dom0 also. Now I see that dom4 *never* gets
> scheduled (I ran the workload for almost one minute wall clock time).
> The only dom switches are between dom0 and idle domain. If both the
> dom0 and dom4 have equal share of the cpu (since I have not specified
> otherwise) shouldn't the dom4 also be scheduled? Am I missing
> something?
>
> I would really appreciate it if someone can shed some light on these 
> questions.
>
> Thanks.
>

_______________________________________________
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®.