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

[Juergen Gross <jgross@xxxxxxxx>]

On 01/04/2019 10:19, Andrew Cooper wrote:
> 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.

Fine with me.


Juergen

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