Re: [PATCH RFC] xen/sched: Optimise when only one scheduler is compiled in

From: Juergen Gross <jgross@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Jan Beulich" <JBeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"Dario Faggioli" <dfaggioli@suse.com>
Subject: Re: [PATCH RFC] xen/sched: Optimise when only one scheduler is compiled in
Date: Thu, 3 Mar 2022 11:14:51 +0100	[thread overview]
Message-ID: <78e6dc12-9406-743c-1fe2-4214483f08fb@suse.com> (raw)
In-Reply-To: <4270d03c-50a9-b1aa-dc2e-53e998153a6b@suse.com>

[-- Attachment #1.1.1: Type: text/plain, Size: 1634 bytes --]

On 03.03.22 09:33, Juergen Gross wrote:
> On 03.03.22 01:40, Andrew Cooper wrote:
>> When only one scheduler is compiled in, function pointers can be 
>> optimised to
>> direct calls, and the hooks hardened against controlflow hijacking.
>>
>> RFC for several reasons.
>>
>> 1) There's an almost beautiful way of not introducing MAYBE_SCHED() 
>> and hiding
>>     the magic in REGISTER_SCHEDULER(), except it falls over
>>     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91765 which has no 
>> comment or
>>     resolution at all.
>>
>> 2) A different alternative which almost works is to remove the 
>> indirection in
>>     .data.schedulers, but the singleton scheduler object can't be both 
>> there
>>     and in .init.rodata.cf_clobber.
>>
>> 3) I can't think of a way of build time check to enforce that new 
>> schedulers
>>     get added to the preprocessor magic.
>>
>> And the blocker:
>> 4) This isn't compatible with how sched_idle_ops get used for 
>> granularity > 1.
>>
>> Suggestions very welcome.
> 
> Did you consider to generate the needed code dynamically instead?
> 
> I guess this could even be extended to avoid function pointers
> completely using the same technique as in my hypercall series.
> 
> In order to avoid the need for a central table the per-scheduler
> hooks could use standard names (as most of them do already).
> 
> I think I could come up with a patch in a few hours if you like
> that approach.

BTW, in theory this approach could be generalized for other function
vectors in the hypervisor, too (maybe even all?).

Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3151 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]