Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 22 Jun 2023 13:15:52 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Juergen Gross <jgross@suse.com>
Cc:     Per Bilse <Per.Bilse@citrix.com>,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
        "open list:X86 ENTRY CODE" <linux-kernel@vger.kernel.org>,
        "moderated list:XEN HYPERVISOR INTERFACE" 
        <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] Updates to Xen hypercall preemption
Message-ID: <20230622111552.GI4253@hirez.programming.kicks-ass.net>
References: <20230621151442.2152425-1-per.bilse@citrix.com>
 <20230621164038.GM2053369@hirez.programming.kicks-ass.net>
 <6523f3e2-8dfc-c2dd-6d14-9e0c3ac93cc8@citrix.com>
 <20230621200409.GC4253@hirez.programming.kicks-ass.net>
 <a8cd2788-a695-964a-3311-dbecb669bb72@suse.com>
 <20230622082607.GD4253@hirez.programming.kicks-ass.net>
 <4d29bfe0-975a-c97f-3e79-5b77d95d3494@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <4d29bfe0-975a-c97f-3e79-5b77d95d3494@suse.com>
Precedence: bulk

On Thu, Jun 22, 2023 at 12:33:31PM +0200, Juergen Gross wrote:
> On 22.06.23 10:26, Peter Zijlstra wrote:

> > > The downside would be that some workloads might see worse performance
> > > due to backend I/O handling might get preempted.
> >=20
> > Is that an actual concern? Mark this a legaxy inteface and anybody who
> > wants to get away from it updates.
>=20
> It isn't that easy. See above.

Well, the old stuff gets to use full preemption on Dom0, then the new
stuff gets more shiny options.

> > > Just thinking - can full preemption be enabled per process?
> >=20
> > Nope, that's a system wide thing. Preemption is something that's driven
> > by the requirements of the tasks that preempt, not something by the
> > tasks that get preempted.
>=20
> Depends. If a task in a non-preempt system could switch itself to be
> preemptable, we could do so around hypercalls without compromising the
> general preemption setting. Disabling preemption in a preemptable system
> should continue to be possible for short code paths only, of course.

So something along those lines was suggested elsewhere, and I'm still
not entirely sure how I feel about it, but look here:

  https://lkml.kernel.org/r/20230403052233.1880567-1-ankur.a.arora@oracle.c=
om

Specifically patches 7 and 8. It is very close so that you currently
do/want. Those patches are many moons old and i've not seen an update on
them, so I've no idea where they are.

It solves a similar problem except it is 'rep string' instructions
that's being interrupted.