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 2508AC433EF for ; Thu, 16 Dec 2021 13:24:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B2126B0074; Thu, 16 Dec 2021 08:23:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 661886B0075; Thu, 16 Dec 2021 08:23:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 528FF6B0078; Thu, 16 Dec 2021 08:23:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay034.a.hostedemail.com [64.99.140.34]) by kanga.kvack.org (Postfix) with ESMTP id 42DD86B0074 for ; Thu, 16 Dec 2021 08:23:49 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 06F04C3F for ; Thu, 16 Dec 2021 13:23:39 +0000 (UTC) X-FDA: 78923724558.03.0EFDFDF Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 893BC4001C for ; Thu, 16 Dec 2021 13:23:38 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1639661016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uHDlt/HgQV9SB/CETbsCPHdj+DyjQBUg5mN4biUJiq0=; b=uS8VK2zstKjBJALe5V5SLqq17N7d8WeWhQ31xBbSrV6xW9TiccgvBu0RtOepEIhr8VYNoj TO35K1pXGBFr8rwTNvCZKzJRvWC2FIvOaLeTlkltwMe5PKrUiGbwGRc9G8Uoa3zrGTiKFz pdLDXRvC8Vo5xii75fR5IsqbjlD5WgBGSMS7MRmS7MB+7QXlROkfV0BVl5PA4BHARARdp+ C6ewhfJNGGkkb06EGhxNPFxJQ3Xi1EmOdpCOuKiy67nak5d131yHh9lrmmi8il95Qpyr1o WCsWZ96VfNK/ozy+2Np2cYyQBRqytABHImgOjuvuOSyXLFsIfXpjkIr+kUAUYQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1639661016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uHDlt/HgQV9SB/CETbsCPHdj+DyjQBUg5mN4biUJiq0=; b=lTbaVuGdSjicH5fAaadv8EWyCHPRMVu8kQRTNDafztc59q4IXBgfpI4G4ChcA6TolZv42L KF8M5eVZp7cGuzAQ== To: Peter Oskolkov , Peter Zijlstra Cc: Peter Oskolkov , Ingo Molnar , juri.lelli@redhat.com, Vincent Guittot , dietmar.eggemann@arm.com, Steven Rostedt , Ben Segall , mgorman@suse.de, bristot@redhat.com, Linux Kernel Mailing List , Linux Memory Management List , linux-api@vger.kernel.org, x86@kernel.org, Paul Turner , Andrei Vagin , Jann Horn , Thierry Delisle Subject: Re: [RFC][PATCH 0/3] sched: User Managed Concurrency Groups In-Reply-To: References: <20211214204445.665580974@infradead.org> <20211215222524.GH16608@worktop.programming.kicks-ass.net> Date: Thu, 16 Dec 2021 14:23:36 +0100 Message-ID: <875yrolm3r.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: tpobp5z5fafa8o68to91amngco3tsxbq X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 893BC4001C Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=uS8VK2zs; dkim=pass header.d=linutronix.de header.s=2020e header.b=lTbaVuGd; spf=pass (imf07.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-HE-Tag: 1639661018-808939 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: Peter, On Wed, Dec 15 2021 at 15:26, Peter Oskolkov wrote: > On Wed, Dec 15, 2021 at 2:25 PM Peter Zijlstra wrote: >> > - take a userspace (spin) lock (so the steps below are all within a >> > single critical section): >> >> Don't ever suggest userspace spinlocks, they're horrible crap. > > This can easily be a mutex, not really important (although for very > short critical sections with only memory reads/writes, like here, spin > locks often perform better, in our experience). Performance may be better, but user space spinlocks have a fundamental problem: They are prone to live locks. That's completely independent of the length of the critical section, it even can be empty. There are ways to avoid that, but that needs a very careful design on the application/library level and at the system configuration level (priorities, affinities ...). And even then, there are trival ways to break that, e.g. via CPU hotplug. So no, for something of general use, they are a complete NONO. People who think they know what they are doing have the source and can replace them if they feel the need to do so. Thanks, tglx