Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1410322pxb; Fri, 21 Jan 2022 18:02:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJxs6cYbSCbB/sEIH0NWE1fxngQq9rLKnnHpDOvbdDoV05Du2Ou7IJX/hFcWeSzCStbskxbt X-Received: by 2002:a17:90b:33d2:: with SMTP id lk18mr3325605pjb.37.1642816938898; Fri, 21 Jan 2022 18:02:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642816938; cv=none; d=google.com; s=arc-20160816; b=gkQ9n4OdbZKkobxaYi5bBfq0U1VoKJQSPxi+i8JG5mAahEFd8XG7vvcBibOIMuDW/d sR+JA4Aj0PLaOMkz8xRRua63DWOkMOs5pdmcx/xLEAdSSdUhWqk14eYSS1UjROmEbBfs 0+dQ1L+dCBBWNq3RBMFpN1OhQ45yTREkKrxoT1g66t/TyvGKL8AJ7JatrJoyU9NxciX6 4JHQKQ+FqC+4Thrz7gMyKO5U4ORHLrRPTp4iUfbfzsHKWgsh9hhP5RtO9gESlTNahoww Jwjun9Rj3MNtqbdTsI5JOBT/hKmEsGiipplev9P8dNdUhThh/boSkWD07IVAUYNKLRDI P/sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=0j/lViCZqpejcvCm7AzuIiC7Ohh74H3kzXbt1rbvd9A=; b=pRxwpgzAq9ZUMoMD7ynm2kqky1Iar3s7zMJSXYDm7rANfCjcU58bWn0RsHBbdl3THu IjfVkdfPAkJlesHp5QP/fFqozUZalw5CZjkINS7izs9KlYiEvz14ZFzv8QccYznEWdYH nQ3bzZhBBBh55dnbyabdugFRoFg19L8P1TDh8oAyr5mXg2qVReh1loCrJ6WYK98GOPGJ GiBpon7UtXwMYdq3Rq7QmDYTBrTGf5nudgLXrtwmUnRhuTbcg3HaPnloOHtzyG1aG1gX xIsqJukFI2I2cKFNBjBf35/rK2TlVz/oeCAim1JgJvyaYq3fSqrLB2Ik8QfOLQpYMoDe 7yaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s17si7255753pgm.852.2022.01.21.18.02.06; Fri, 21 Jan 2022 18:02:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380418AbiAUQ6q (ORCPT + 99 others); Fri, 21 Jan 2022 11:58:46 -0500 Received: from foss.arm.com ([217.140.110.172]:56662 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1380415AbiAUQ5g (ORCPT ); Fri, 21 Jan 2022 11:57:36 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 47AE51FB; Fri, 21 Jan 2022 08:57:35 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.1.33]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B3723F73D; Fri, 21 Jan 2022 08:57:32 -0800 (PST) Date: Fri, 21 Jan 2022 16:57:29 +0000 From: Mark Rutland To: Peter Zijlstra Cc: mingo@redhat.com, tglx@linutronix.de, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, x86@kernel.org, pjt@google.com, posk@google.com, avagin@google.com, jannh@google.com, tdelisle@uwaterloo.ca, posk@posk.io Subject: Re: [RFC][PATCH v2 5/5] sched: User Mode Concurency Groups Message-ID: References: <20220120155517.066795336@infradead.org> <20220120160822.914418096@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220120160822.914418096@infradead.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 20, 2022 at 04:55:22PM +0100, Peter Zijlstra wrote: > User Managed Concurrency Groups is an M:N threading toolkit that allows > constructing user space schedulers designed to efficiently manage > heterogeneous in-process workloads while maintaining high CPU > utilization (95%+). > > XXX moar changelog explaining how this is moar awesome than > traditional user-space threading. Awaiting a commit message that I can parse, I'm just looking at the entry bits for now. TBH I have no idea what this is actually trying to do... [...] > --- a/include/linux/entry-common.h > +++ b/include/linux/entry-common.h > @@ -23,6 +23,10 @@ > # define _TIF_UPROBE (0) > #endif > > +#ifndef _TIF_UMCG > +# define _TIF_UMCG (0) > +#endif > + > /* > * SYSCALL_WORK flags handled in syscall_enter_from_user_mode() > */ > @@ -43,11 +47,13 @@ > SYSCALL_WORK_SYSCALL_EMU | \ > SYSCALL_WORK_SYSCALL_AUDIT | \ > SYSCALL_WORK_SYSCALL_USER_DISPATCH | \ > + SYSCALL_WORK_SYSCALL_UMCG | \ > ARCH_SYSCALL_WORK_ENTER) > #define SYSCALL_WORK_EXIT (SYSCALL_WORK_SYSCALL_TRACEPOINT | \ > SYSCALL_WORK_SYSCALL_TRACE | \ > SYSCALL_WORK_SYSCALL_AUDIT | \ > SYSCALL_WORK_SYSCALL_USER_DISPATCH | \ > + SYSCALL_WORK_SYSCALL_UMCG | \ > SYSCALL_WORK_SYSCALL_EXIT_TRAP | \ > ARCH_SYSCALL_WORK_EXIT) > > @@ -221,8 +227,11 @@ static inline void local_irq_disable_exi > */ > static inline void irqentry_irq_enable(struct pt_regs *regs) > { > - if (!regs_irqs_disabled(regs)) > + if (!regs_irqs_disabled(regs)) { > local_irq_enable(); > + if (user_mode(regs) && (current->flags & PF_UMCG_WORKER)) > + umcg_sys_enter(regs, -1); > + } > } Perhaps it would make sense to have separate umcg_sys_enter(regs) and umcg_sys_enter_syscall(regs, syscallno)? Even if the former is just a wrapper, to make the entry/exit bits clearly correspond for all the !syscall cases? Also, is the syscall case meant to nest within this, or syscall entry paths not supposed to call irqentry_irq_enable() ? > > /** > @@ -232,8 +241,11 @@ static inline void irqentry_irq_enable(s > */ > static inline void irqentry_irq_disable(struct pt_regs *regs) > { > - if (!regs_irqs_disabled(regs)) > + if (!regs_irqs_disabled(regs)) { > + if (user_mode(regs) && (current->flags & PF_UMCG_WORKER)) > + umcg_sys_exit(regs); > local_irq_disable(); > + } > } Do the umcg_sys_{enter,exit}() calls need to happen with IRQs unmasked? * If not (and this nests): for arm64 these can live in our enter_from_user_mode() and exit_to_user_mode() helpers. * If so (or this doesn't nest): for arm64 we'd need to rework our local_daif_{inherit,restore,mask}() calls to handle this, though I've been meaning to do that anyway to handle pseudo-NMI better. Either way, it looks like we'd need helpers along the lines of: | static __always_inline void umcg_enter_from_user(struct pt_regs *regs) | { | if (current->flags & PF_UMCG_WORKER) | umcg_sys_enter(regs, -1); | } | | static __always_inline void umcg_exit_to_user(struct pt_regs *regs) | { | if (current->flags & PF_UMCG_WORKER) | umcg_sys_exit(regs); | } Thanks, Mark.