[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 08/49] xen/sched: use new sched_item instead of vcpu in scheduler interfaces



On Mon, 2019-04-01 at 09:19 +0100, Andrew Cooper wrote:
> On 01/04/2019 08:05, Dario Faggioli wrote:
> > On Mon, 2019-04-01 at 08:06 +0200, Juergen Gross wrote:
> > > The
> > > wrappers could then call the related specific scheduler function
> > > based
> > > on the scheduler Id using a chain of if ... else if ...
> > > statements. 
> > > 
> > I guess we'd have to see how the final code will look, but I like
> > the
> > idea, and I think it's well worth a try.
> 
> Normally, the result is put together with PGO rather than manually,
> because the effects are quite subtle.
> 
> The base case which might be good enough for Xen is:
> 
> if ( sched == default )
>     sched_foo();
> else
>     sched->foo();
> 
Yep, and this was exactly what I had in mind, before a full 'if..else'
was mentioned here. And if that's as far as it's sane to get, I'm fine
with that.

> which for the common case of the default cpupool only, or multiple
> groups with the same scheduler, will always take the direct path
> rather
> than the indirect path.
> 
Yeah, and as far as I've been seeing, using default scheduler and
pretty much ignoring cpupool is common enough (and I'm not saying it's
too great a thing! :-/)

> Beyond that, the best length of the if/else chain can only reasonably
> be
> determined with profiling.  It depends on the relative frequencies of
> each call, and blindly doing an if/else chain to the end of the
> scheduler list will probably make worse performance if you're using
> the
> final scheduler than using a retpoline would.  
>
Yeah, makes sense.

And anyway...

> I think its useful to consider optimisations potential optimisations,
> but I'd advise against trying to merge everything into this series.
> 
...yes, let's keep this for later.

Regards,
Dario
-- 
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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.