From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C180C433EF for ; Fri, 21 Jan 2022 16:57:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B3C3A6B0080; Fri, 21 Jan 2022 11:57:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AEB026B0083; Fri, 21 Jan 2022 11:57:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A01636B0085; Fri, 21 Jan 2022 11:57:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id 918276B0080 for ; Fri, 21 Jan 2022 11:57:37 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4499789095 for ; Fri, 21 Jan 2022 16:57:37 +0000 (UTC) X-FDA: 79054900554.27.B2E81FF Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf29.hostedemail.com (Postfix) with ESMTP id 15CC0120008 for ; Fri, 21 Jan 2022 16:57:35 +0000 (UTC) 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> X-Rspamd-Queue-Id: 15CC0120008 X-Stat-Signature: xxoshiczjq1bdkaxizs8x8yycxno3y68 Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com; dmarc=pass (policy=none) header.from=arm.com X-Rspamd-Server: rspam03 X-HE-Tag: 1642784255-458962 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.