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

Re: [Xen-devel] How to Stop scheduler


  • To: Pankaj Parakh <me.pankajparakh@xxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Thu, 5 Nov 2009 09:55:34 +0000
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 05 Nov 2009 01:56:22 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vtOijWYd937uQkNBwK5R637rM3nvPDE6JVJ5EDTb2uNKBSVLU84qTxDcAHxyEDWU1e lrOm/k+d5s33TOSHtDV3B0EZx5oXri4P9fB4o25sCtXtm4uhrXQC18oZZVrcPXR4EnUd bIKF3WP8U0h+8XiKrO4biDE01rs2KoOe3/PrM=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

I assume you mean, once you've paused current(), how do you get into
the scheduler to actually get it off the cpu?

In Linux, you can call schedule() because each process has its own
kernel stack allocated to it; the stack "remembers" where each process
was in the kernel, so you can return from schedule() at the same place
in the kernel once you're scheduled again.

Xen only has one stack per cpu, so it cannot keep track of where *in
the hypervisor* a vcpu is that gets scheduled out.  Therefore, you
can't call schedule() directly, as it would throw away the stack.  You
must raise SCHEDULE_SOFTIRQ on the current cpu, and then return back
to the guest.  On the way out, the softirq will call schedule() and
switch to another vcpu if necessary.  (It will only schedule the idle
process if there are no runnable vcpus.)

grep for SCHEDULE_SOFTIRQ to see examples of how this is used in Xen.

 -George

On Thu, Nov 5, 2009 at 12:43 AM, Pankaj Parakh
<me.pankajparakh@xxxxxxxxx> wrote:
> How can I schedule idle vcpu voluntarily without using schedule() ??
> Is there any function for it already defined, or do I have to follow
> some steps.. ??
>
> On Wed, Nov 4, 2009 at 5:09 PM, George Dunlap
> <George.Dunlap@xxxxxxxxxxxxx> wrote:
>>
>> On Wed, Nov 4, 2009 at 5:59 AM, Pankaj Parakh <me.pankajparakh@xxxxxxxxx> 
>> wrote:
>> > If I take domain_update_lock for  a domain, what will happen to its
>> > interrupts for IO completions or any other type..??
>> > And will it be scheduled if I hold that lock..??
>>
>> Have you looked at the interrupt delivery / IO completion path, or the
>> scheduler path, to see if those are affected by the
>> domain_update_lock()?
>>
>> Xen is a bit of a twisted web; sometimes you just have to follow a web
>> of logic around to find out what you're looking for; then, once you've
>> come to a conclusion, test it by writing some code.
>>
>> For the scheduling question, you might start with looking at vcpu_runnable().
>>
>> Peace,
>>  -George
>>
>> >
>> > On Wed, Nov 4, 2009 at 11:08 AM, Pankaj Parakh <me.pankajparakh@xxxxxxxxx>
>> > wrote:
>> >>
>> >> So is that means there will be no interrupt loss, and also clock in
>> >> the paused domain will be in right and expected time.. ??
>> >>
>> >> On Wed, Nov 4, 2009 at 12:41 AM, George Dunlap
>> >> <george.dunlap@xxxxxxxxxxxxx> wrote:
>> >> > If you call vcpu_pause(), it atomically increments a counter in the vcpu
>> >> > struct.  While that counter is non-zero, the vcpu *will not* be
>> >> > scheduled,
>> >> > interrupts or no.  Interrupts will be delivered when it's scheduled
>> >> > again.
>> >> >
>> >> > -George
>> >> >
>> >> > Pankaj Parakh wrote:
>> >> >>
>> >> >>  If I pause a vcpu/domain using those functions, say if a domain's I/O
>> >> >> request over then its interrupt will raise and it can restart its
>> >> >> scheduling rite..?? How this interrupts are/ can be queued so that
>> >> >> when the vcpu is in pause state, it should nat change its state and
>> >> >> when it come back to wait state, those interrupt will not be lost..
>> >> >>
>> >> >> On Tue, Nov 3, 2009 at 5:18 PM, George Dunlap
>> >> >> <George.Dunlap@xxxxxxxxxxxxx> wrote:
>> >> >>
>> >> >>>
>> >> >>> Do you mean that you want to stop one specific vcpu / domain from
>> >> >>> being scheduled?
>> >> >>>
>> >> >>> If so, you're looking for the following functions:
>> >> >>> vcpu_pause(), vcpu_unpause()
>> >> >>> domain_pause(), domain_unpause().
>> >> >>>
>> >> >>> They're defined in xen/common/domain.c.
>> >> >>>
>> >> >>>  -George
>> >> >>>
>> >> >>>
>> >> >>> On Mon, Nov 2, 2009 at 9:02 PM, Pankaj Parakh
>> >> >>> <me.pankajparakh@xxxxxxxxx>
>> >> >>> wrote:
>> >> >>>
>> >> >>>>
>> >> >>>> Hi All,
>> >> >>>>
>> >> >>>> I am working on a project wherein I wanted to stop the scheduling
>> >> >>>> activity in hypervisor through 'generic' part of scheduler, I have
>> >> >>>> lil
>> >> >>>> confusion as to what all things I need to mask/stop for disabling
>> >> >>>> hypervisor to schedule any vcpu untill I want.
>> >> >>>>
>> >> >>>> Issues which I can think are about I/O waits or Zombie VCPUs. But how
>> >> >>>> to tackle them... I dont know..
>> >> >>>>
>> >> >>>> I wanted to know what all responsibility the generic scheduler holds
>> >> >>>> in hypervisor,
>> >> >>>>
>> >> >>>> Any type of info or pointer can be useful.
>> >> >>>>
>> >> >>>> Thanks
>> >> >>>> Pankaj Parakh
>> >> >>>>
>> >> >>>> _______________________________________________
>> >> >>>> Xen-devel mailing list
>> >> >>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> >> >>>> http://lists.xensource.com/xen-devel
>> >> >>>>
>> >> >>>>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Pankaj Parakh
>> >
>> >
>> >
>> > --
>> > Pankaj Parakh
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@xxxxxxxxxxxxxxxxxxx
>> > http://lists.xensource.com/xen-devel
>> >
>> >
>
>
>
> --
> Pankaj Parakh
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

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