Re: [Xen-devel] [PATCH v2 2/2] sched_credit2.c: runqueue_per_core code

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 03/18/2015 04:49 PM, Dario Faggioli wrote:
>> scheduler_init() is called before smp_prepare_cpus() in part because of
>> a dependency chain elsewhere: we cannot set up the idle domain until
>> scheduler_init() is called; and other places further on in the
>> initialization but before setting up cpu topology information assume
>> that the idle domain has been set up.
>>
> However, as you say yourself below, there is boot_cpu_data, which
> stashes the info we need for the boot cpu. It gets filled after
> init_idle_domain()->scheduler_init() right now, but I don't see a reason
> why it can't be pulled up a bit (and from my tests, it seems to work).

Well yes, my goal was first to primarily talk about the state of the
world and get all the facts and constraints out there; and then after
that to talk about what we can / could do to fix it. :-)

I do think we want to minimize the special casing as much as possible;
and I think it makes sense for setup to be the one trying to sort out
constraints, rather than the callees: i.e., for setup to say, "I know
scheduler_init may need the topology information for this cpu to be in
cpu_data[], so I'm going to make sure that's in place before I call it".

So if it's possible to arrange for cpu_data[] to be populated -- at
least with the topology information -- for each cpu before alloc_pdata
happens, I think that's ideal.

>> If this would work, I think it would be a lot better.  It would remove
>> the credit2-specific callback, and it would mean we wouldn't need an
>> additional test to filter out
>>
> I see. Ok, I guess I can give this a try. If it does not explode,
> because some weird dependency we can't see right now, we can either try
> harder to track it, or use the other solution outlined above as a
> fallback.

If you could look into this, that would be awesome. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel