From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 1/1] Xen ARINC 653 Scheduler (updated to add support for CPU pools) Date: Thu, 17 Jun 2010 08:04:01 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Kathy Hadley , George Dunlap Cc: "xen-devel@lists.xensource.com" , Gross , Juergen List-Id: xen-devel@lists.xenproject.org On 16/06/2010 19:03, "Kathy Hadley" 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 >=20 >> -----Original Message----- >> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >> Sent: Wednesday, June 16, 2010 12:50 PM >> To: Kathy Hadley; George Dunlap >> Cc: xen-devel@lists.xensource.com; Juergen Gross >> Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated >> to add support for CPU pools) >>=20 >> 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? >>=20 >> -- Keir >>=20 >> On 16/06/2010 17:40, "Kathy Hadley" >> wrote: >>=20 >>> Keir, George, et. al., >>> I definitely saw two "ops" values. When the .init function was >> called, ops >>> =3D 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 =3D 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). >>>=20 >>> Regards, >>> Kathy >>>=20 >>>> -----Original Message----- >>>> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >>>> Sent: Wednesday, June 16, 2010 12:32 PM >>>> To: Kathy Hadley; George Dunlap >>>> Cc: xen-devel@lists.xensource.com; Juergen Gross >>>> Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler >> (updated >>>> to add support for CPU pools) >>>>=20 >>>> On 16/06/2010 17:25, "Kathy Hadley" >>>> wrote: >>>>=20 >>>>> Keir, >>>>> I only saw the .init function called once. I downloaded xen- >>>> unstable on May >>>>> 27. Were your updates after that? >>>>=20 >>>> 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. >>>>=20 >>>> -- Keir >>>>=20 >>>>> Thanks, >>>>> Kathy Hadley >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >>>>>> Sent: Wednesday, June 16, 2010 12:20 PM >>>>>> To: George Dunlap; Kathy Hadley >>>>>> Cc: xen-devel@lists.xensource.com; Juergen Gross >>>>>> Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler >>>> (updated >>>>>> to add support for CPU pools) >>>>>>=20 >>>>>> On 16/06/2010 17:14, "George Dunlap" >>>>>> wrote: >>>>>>=20 >>>>>>>> =A0I actually tried the xmalloc() method first. =A0I 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. =A0I 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. =A0Suggestions? >>>>>>>=20 >>>>>>> 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? >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> -- Keir >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20