Re: [Xen-devel] [PATCH v2 08/48] xen/sched: switch vcpu_schedule_lock to unit_schedule_lock

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Wed, 2019-09-04 at 17:02 +0200, Juergen Gross wrote:
> On 04.09.19 16:54, Jan Beulich wrote:
> > On 04.09.2019 16:41, Juergen Gross wrote:
> > > On 04.09.19 16:02, Jan Beulich wrote:
> > > > 
> > > > At the example of this: The more coarse granularity of the lock
> > > > means that no two vCPU-s within a unit can obtain their
> > > > runstate
> > > > in parallel. While this may be acceptable for core scheduling,
> > > > I'm afraid it's too restrictive for sockets or nodes as units.
> > > > Therefore I think this lock needs to either be split (I'm not
> > > > sure that's feasible) or become an r/w lock.
> > > 
> > > You are aware that even today with credit2 all cpus of a socket
> > > share
> > > the same lock (if not modified via boot parameter)?
> > 
> > No, I wasn't (explicitly; I could have deduced it). Not very
> > helpful,
> > I'm afraid, but unlikely to be bad enough to go back to credit1
> > (but
> > people having an issue with this could be told to switch back).
> 
> Well, performance tests have shown that this is the most performant
> setting. And before going back to credit1 they still can use another
> lock setting (core or cpu).
> 
Yeah, but it's not only locking. It's the entire load balancing
mechanism.

And yes, the scalability test we did showed that per-socket runqueues
was better. I think it is possible to improve locking scalability of
Credit2 (or, at least, I have some ideas.. but no code yet).

All that being said, I think it would be rather difficult to implement
sub-unit locking. And I don't think it's worth to do it right now, out
of concerns of potential scalability issues for socket-scheduling.

We're discussing about merging core-scheduling, but keeping it disabled
for now. We're not even sure if/when people will start to use *it*. I
currently don't see much use cases for socket-scheduling (although it
is indeed cool that we get the implementation basically for free!), and
hence I won't block patches or complicate the work for something like
that.

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

Attachment: signature.asc
Description: This is a digitally signed message part

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