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)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
