On 01/04/2019 08:05, Dario Faggioli wrote: > On Mon, 2019-04-01 at 08:06 +0200, Juergen Gross wrote: >> On 30/03/2019 11:24, Juergen Gross wrote: >>> I think its is easier to do it myself, as I'm touching nearly all >>> of >>> the call sites anyway. >> And another thought I had: with RETPOLINE indirect jumps are even >> more >> expensive. Would it be a good idea to remove the function pointers >> from >> struct scheduler and generate the inline wrappers at build time? >> > Yep, I was thinking about doing something like that already, > independently from this feature/series. > > At least something that special case the configured default scheduler, > and let its hooks be called without indirect jumps (i.e., similarly to > what's being done in Linux, in quite a few places, these days). > >> 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.
Jan has a series in progress which does do some manual devirtualisation across Xen. The scheduler is harder though - we've got the default scheduler which is overwhelmingly likely to be the target of the call, but not always guaranteed. 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(); 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. 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. Furthermore, on future fixed hardware, using indirect calls will become the quicker option again. I think its useful to consider optimisations potential optimisations, but I'd advise against trying to merge everything into this series. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
