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

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


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 3 Mar 2022 09:24:12 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6AU69iuTQOnoOEvUGyViPRsMi+Wh140ZpZc3DakmUaI=; b=QPc46aVVuMqxETgDo/XVA4OuVO07OqEPs3KWGpKnAHw7ci7Ekt8DnJT1R1zwf9FFCD0OovoqUBnMQ/ChS0hqNmnGIGjuRvx1vouuZSC5SYc2OhJxbV2t59fKmXBdS1psvePUt0nVwXWpN1Jqek8FJPAYTu2CmS33WhQmndQkvBIcUnhJxHhxpeqIzRwgWnmCm4nb/c9l5AU6m4qOFxzU8YoEkD0+++TxGrbS6I6PmzCxhAZ5g2rhBxuPovRRvaVmejjAdqBtenu2vgev6fROJaLp+c2Y+KyBlrpsnzehxXHdJxIJjk+gB+vcUeCrvP+rCNDNLFM3gYat1UIjg9lPfg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l7WjK3U8df+aE1diap8m9XBP8ssbnEc8mrp7ra83YSfyNUVoRLBgQ4gqA4YWVB519Cvfv8SFJLF1ecw5C/S0j9gJj+F0uSm7sDOjl9D55WrPSS0TdTzrAM/90scMvtd9PHFRzKsu7apbh1DmQ8JGTwY/5z79MADXnqvOwBP8OQ1cif2ewR6Zc9ArG0ZpbyODtVd6FQjfFYd7VSUg0GNMu+tjk70EmOZKOCoWlL3e4BenDRkd1/JEkS6V4YfEpLXTVfevmXTP74sXJH2K4Q1vpdTqN5gKMRAO94ssr8OeN6FO4VpRMpOe3rfAE/7V6mFufYJ0s/4oB7y6u3/YjiPWiA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 03 Mar 2022 08:24:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.03.2022 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.

Couldn't we name the section differently when there's just one member,
placing that section inside __initdata_cf_clobber_{start,end} in the
linker script?

> 3) I can't think of a way of build time check to enforce that new schedulers
>    get added to the preprocessor magic.

An assertion in the linker script, checking that .data.schedulers has a
single entry when the sched_ops symbol exists? This may involve a
PROVIDE(sched_ops = 0) as there doesn't look to be a way to probe for
symbol defined-ness in expressions.

> And the blocker:
> 4) This isn't compatible with how sched_idle_ops get used for granularity > 1.

Special case it just like we special case plt_tsc in x86/time.c?

> --- a/xen/common/sched/private.h
> +++ b/xen/common/sched/private.h
> @@ -271,6 +271,33 @@ static inline spinlock_t *pcpu_schedule_trylock(unsigned 
> int cpu)
>      return NULL;
>  }
>  
> +#if 1 ==                                                                \
> +    defined(CONFIG_SCHED_CREDIT) + defined(CONFIG_SCHED_CREDIT2) +      \
> +    defined(CONFIG_SCHED_RTDS) + defined(CONFIG_SCHED_ARINC653) +       \
> +    defined(CONFIG_SCHED_NULL)
> +
> +extern const struct scheduler sched_ops;
> +#define MAYBE_SCHED(x) __initdata_cf_clobber sched_ops

__initconst_cf_clobber, seeing that all use sites also use const?

> @@ -333,39 +360,48 @@ struct scheduler {
>      void         (*dump_cpu_state) (const struct scheduler *, int);
>  };
>  
> +static inline int sched_global_init(const struct scheduler *s)
> +{
> +    if ( s->global_init )
> +        return sched_call(s, global_init);
> +    return 0;
> +}

Is it really a good idea to expose this here when it's supposed to be
used from core.c only, and even there in just a single place?

Jan




 


Rackspace

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