Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable schedulers.

[Dario Faggioli <raistlin@xxxxxxxx>]

On Tue, Dec 6, 2011 at 11:34 AM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>> Given that every scheduler plugin is going to need this lock perhaps it
>> could be provided globally (but still have the responsibility for using
>> it fall on the plugin)?
>
> Sorry for the long delay in responding... I don't really like this idea.
> For one thing, that would make the generic scheduler code responsible
> for making per-cpupool locks, which could look messy, and adds to code
> complexity.
>
Right. I was looking into this and facing right this issue, i.e., how to make
that lock a per-cpupool thing, and wasn't quite succeeding in doing that
in a clean way.

> I also think that logically, having each scheduler in charge
> of its own locking makes more sense; having the generic scheduling code
> do stuff on behalf of the pluggable scheduler is what caused this
> problem in the first place.
>
Indeed.

> If we think having a one-item struct is ugly, could we just use
> spinlock_t as the type we allocate / cast to in the sedf scheduler?
>
Well, I put that struct there in the first place so I definitely can live
with it. I certainly don't think it is the most beautiful piece of code
I've ever wrote but, considering I'd have to dynamically allocate the
lock anyway (for the reasons above), and access it through
ops->sched_data, having it pointing directly to the lock is not that
much better than the struct to me.

Therefore, I think I'll let you decide here, and will keep or kill the
struct basing on what you think is nicer! :-)

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

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