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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1561 bytes --]

On Thu, 2015-03-19 at 12:35 +0000, George Dunlap wrote:
> On 03/19/2015 12:29 PM, Dario Faggioli wrote:

> > So, if I can ask, how about my idea of splitting alloc_ and init_ parts
> > of pCPU initialization ? :-)
> 
> Architecturally, from some points of view it makes sense
>
It does, doesn't it? That's why I like it: it fixes the issue we have,
but in an architecturally sensible and non hackish way, IMO.

> from
> other points of view, it would be nicer not to multiply callbacks and
> make the interface more complicated.
> 
I see what you mean, and I agree. Well, from an arithmetic point of
view, this will allow us to get rid of the .global_init hook, so the
numbers of hook will be unchanged! ;-P

Jokes apart, complexity has to be added to solve the issue, it's either
this patch or the one from earlier in the thread which checked
system_state==SYS_STATE_boot in csched2_alloc_pdata  (with the added >=
SYS_STATE_active for the cpupool case, of course).

As you said in the first place, reducing dependencies, or at least
making them easier to track, it's of some value, and I think the
alloc_/init_ splitting approach goes in that direction.

> But from a practical point of view, this path is already more work than
> I was expecting it to be, so I don't think we should spend *too* much
> time looking for alternatives.  If that seems like the best option at
> the moment, then I'm fine with it.
> 
Great. I'll put a proper series together, and let's see how it'll look
like. :-)

Thanks and Regards,
Dario

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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