Re: [Xen-devel] [PATCH 03/60] xen/sched: let sched_switch_sched() return new lock address

[Juergen Gross <jgross@xxxxxxxx>]

On 12.06.19 09:40, Jan Beulich wrote:
> > > > On 11.06.19 at 18:55, <dfaggioli@xxxxxxxx> wrote:
> > On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> > > Instead of setting the scheduler percpu lock address in each of the
> > > switch_sched instances of the different schedulers do that in
> > > schedule_cpu_switch() which is the single caller of that function.
> > > For that purpose let sched_switch_sched() just return the new lock
> > > address.
> > This looks good to me. The only actual functional/behavioral difference
> > I've been able to spot is the fact that, in Credit2, we currently
> > switch the lock pointer while still holding the write lock on the
> > global scheduler. After this change, we don't any longer.
> >
> > That being said, I've tried to think about how this could be a problem,
> > but failed at imagining such a scenario, so:
> >
> > > Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> > Reviewed-by: Dario Faggioli <dfaggioli@xxxxxxxx>
> >
> > I'm wondering whether it make sense for the above to be quickly
> > mentioned in the changelog, but am leaning toward "not really
> > necessary". In particular, I don't think it's worth to respin the patch
> > just for that... So, either just something that can be added while
> > committing, or forget it.
> I'd be happy to add something while committing, but one of you
> would need to propose the wording of this "something".
What about:

It should be noted that in credit2 the lock used to be set while still
holding the global scheduler write lock, which will no longer be true
with the new scheme applied. This is actually no problem as the write
lock is meant to guard the call of init_pdata() which still is true.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel