WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated to add supp

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated to add support for CPU pools)
From: "Kathy Hadley" <Kathy.Hadley@xxxxxxxxxxxxxxx>
Date: Fri, 18 Jun 2010 13:35:12 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 18 Jun 2010 10:36:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C83F8771.17B7B%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <D3E384327F5C6D48AADCEA84160B7D7301470F73@xxxxxxxxxxxxxxx> <C83F8771.17B7B%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcsNbwzA3ljXALi4RuWicdpNTkcsxQAAMAgmAAAadBAAAEvrHQAABmIAAACZp+4AApBeQAAbRt37AEa4JrA=
Thread-topic: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated to add support for CPU pools)
I migrated to c/s 21632 in the staging tree.  I see that 
xen_sysctl_scheduler_op in sysctl.h was updated in c/s 21626 to add cpupool_id 
to the structure.  I call the following function from an application executing 
in Dom0 to adjust the ARINC 653 schedule:

xc_sched_arinc653_sched_set(
    xc_interface *xch,
    xen_sysctl_sched_arinc653_schedule_t * sched)
{
    DECLARE_SYSCTL;

    sysctl.cmd = XEN_SYSCTL_scheduler_op;
    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_ARINC653;
    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_putinfo;
    set_xen_guest_handle(sysctl.u.scheduler_op.u.arinc653.schedule, sched);

    return do_sysctl(xch, &sysctl);
}

In this function, which executes in Dom0, how do I determine the cpupool_id 
that I need to set in the sysctl data structure?

Thank you,
  Kathy Hadley

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Thursday, June 17, 2010 3:04 AM
> To: Kathy Hadley; George Dunlap
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Juergen Gross
> Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated
> to add support for CPU pools)
> 
> On 16/06/2010 19:03, "Kathy Hadley" <Kathy.Hadley@xxxxxxxxxxxxxxx>
> wrote:
> 
> > That sounds reasonable to me.
> 
> Fixed as of changeset 21626, in the staging tree
> (http://xenbits.xensource.com/staging/xen-unstable.hg).
> 
>  K.
> 
> > Kathy
> >
> >> -----Original Message-----
> >> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> >> Sent: Wednesday, June 16, 2010 12:50 PM
> >> To: Kathy Hadley; George Dunlap
> >> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Juergen Gross
> >> Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler
> (updated
> >> to add support for CPU pools)
> >>
> >> Oh, I see. Well, the cause is that the
> >> common/schedule.c:sched_adjust_global() is broken. But, what should
> it
> >> actually do, given that multiple schedulers of same or differing
> types
> >> may
> >> exist in a system now? Perhaps the sysctl should take a cpupool id,
> to
> >> uniquely identify the scheduler instance to be adjusted?
> >>
> >>  -- Keir
> >>
> >> On 16/06/2010 17:40, "Kathy Hadley" <Kathy.Hadley@xxxxxxxxxxxxxxx>
> >> wrote:
> >>
> >>> Keir, George, et. al.,
> >>>   I definitely saw two "ops" values.  When the .init function was
> >> called, ops
> >>> = 0xFF213DC0; I then used xmalloc() to allocate memory for the
> >> scheduler data
> >>> structure and set ops->sched_data equal to the address of that
> memory
> >> block
> >>> (similar to what is done in csched_init in sched_credit.c).  When
> the
> >>> .adjust_global function was called, ops = 0xFF2112D0 and ops-
> >>> sched_data was
> >>> not equal to the address of the memory block allocated in the .init
> >> function
> >>> (it was equal to the value set when "sched_arinc653_def" was
> >> declared).
> >>>
> >>>   Regards,
> >>> Kathy
> >>>
> >>>> -----Original Message-----
> >>>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> >>>> Sent: Wednesday, June 16, 2010 12:32 PM
> >>>> To: Kathy Hadley; George Dunlap
> >>>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Juergen Gross
> >>>> Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler
> >> (updated
> >>>> to add support for CPU pools)
> >>>>
> >>>> On 16/06/2010 17:25, "Kathy Hadley" <Kathy.Hadley@xxxxxxxxxxxxxxx>
> >>>> wrote:
> >>>>
> >>>>> Keir,
> >>>>>   I only saw the .init function called once.  I downloaded xen-
> >>>> unstable on May
> >>>>> 27.  Were your updates after that?
> >>>>
> >>>> My changes were done before May 27, and that ties in with you
> seeing
> >>>> .init
> >>>> called only once. That being the case, you should not see multiple
> >>>> different
> >>>> ops structures ('struct scheduler' instances). The only ops struct
> >> that
> >>>> should exist in the system in this case should be the one
> statically
> >>>> defined
> >>>> near the top of common/schedule.c.
> >>>>
> >>>>  -- Keir
> >>>>
> >>>>>   Thanks,
> >>>>> Kathy Hadley
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> >>>>>> Sent: Wednesday, June 16, 2010 12:20 PM
> >>>>>> To: George Dunlap; Kathy Hadley
> >>>>>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Juergen Gross
> >>>>>> Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler
> >>>> (updated
> >>>>>> to add support for CPU pools)
> >>>>>>
> >>>>>> On 16/06/2010 17:14, "George Dunlap"
> <George.Dunlap@xxxxxxxxxxxxx>
> >>>>>> wrote:
> >>>>>>
> >>>>>>>>  I actually tried the xmalloc() method first.  I found that
> when
> >>>> the
> >>>>>>>> .adjust_global function was called, the address of the "ops"
> >> data
> >>>>>> structure
> >>>>>>>> passed to that function was different from the address of the
> >>>> "ops"
> >>>>>> data
> >>>>>>>> structure when the .init function was called.  I wanted to use
> >>>>>> .adjust_global
> >>>>>>>> to modify the data structure that was created when the .init
> >>>>>> function was
> >>>>>>>> called, but I could not figure out a way to get the address of
> >> the
> >>>>>> second
> >>>>>>>> data structure.  Suggestions?
> >>>>>>>
> >>>>>>> It's been a month or two since I trawled through the cpupools
> >> code;
> >>>>>>> but I seem to recall that .init is called twice -- once for the
> >>>>>>> "default pool" (cpupool0), and once for an actually in-use
> pool.
> >>>>>>> (Juergen, can you correct me if I'm wrong?)  Is it possible
> that
> >>>>>>> that's the difference in the pointers that you're seeing?
> >>>>>>
> >>>>>> Oh yes, that was the old behaviour. I took a hatchet to the
> >>>>>> scheduler/cpupool interfaces a few weeks ago and now we should
> >> only
> >>>>>> initialise the scheduler once, unless extra cpupools are
> manually
> >>>>>> created.
> >>>>>> The fact that Kathy is seeing two different ops structures
> >> probably
> >>>>>> indicates that her xen-unstable tree is very out of date. Which
> >> may
> >>>>>> also
> >>>>>> mean that the patch will not apply to current tip.
> >>>>>>
> >>>>>>  -- Keir
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>