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 B0726C4167B for ; Wed, 6 Dec 2023 10:08:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 594356B0071; Wed, 6 Dec 2023 05:08:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 543F06B0085; Wed, 6 Dec 2023 05:08:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E4A66B0095; Wed, 6 Dec 2023 05:08:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2C98F6B0071 for ; Wed, 6 Dec 2023 05:08:42 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0A48EA0AC5 for ; Wed, 6 Dec 2023 10:08:42 +0000 (UTC) X-FDA: 81535969284.06.2DA1180 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by imf27.hostedemail.com (Postfix) with ESMTP id 8E73D40013 for ; Wed, 6 Dec 2023 10:08:39 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf27.hostedemail.com: domain of david.laight@aculab.com designates 185.58.86.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701857319; a=rsa-sha256; cv=none; b=RqiPEp8wjNueBozIEzq0etLgYlsUu4bgYLCeyoUOKLac67J7eXq9myBOe3epYgkLbOy6Pi 7pgifPaNPfJkXAMbgLNhhdWkuF86Fj1K5hYINy9DSiKLhObCibl3ajDhPpLMEXZm4UWHsH e6U2HlU8UAfqSKyZEzxK8533gqJkDpU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf27.hostedemail.com: domain of david.laight@aculab.com designates 185.58.86.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701857319; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WBV/fxI8ZOkpWULDUVBvYFf9+7nZvEj5s5QPDAF/ru4=; b=Hd82ED3A6vyY518HxfK7EGP5clf75qx/y4oan+CUiIzxC0KAFf9wgDwSH8w13IaJE05/pq 9jSWU5/f0Rs3hrnPO2bu8X9wSZrwbbWSZi/wHl+OlMOTex6GpygBO677Wo4MQA9D9gCKL3 bswKpReEKfvLrcGBfxbLKPqyBk4mxCQ= Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-33-FiOxCgBcM6Sc0jM-G-mxHA-1; Wed, 06 Dec 2023 10:08:34 +0000 X-MC-Unique: FiOxCgBcM6Sc0jM-G-mxHA-1 Received: from AcuMS.Aculab.com (10.202.163.4) by AcuMS.aculab.com (10.202.163.4) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Wed, 6 Dec 2023 10:08:20 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Wed, 6 Dec 2023 10:08:20 +0000 From: David Laight To: 'Steven Rostedt' , "Paul E. McKenney" CC: Thomas Gleixner , Ankur Arora , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "torvalds@linux-foundation.org" , "linux-mm@kvack.org" , "x86@kernel.org" , "akpm@linux-foundation.org" , "luto@kernel.org" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "hpa@zytor.com" , "mingo@redhat.com" , "juri.lelli@redhat.com" , "vincent.guittot@linaro.org" , "willy@infradead.org" , "mgorman@suse.de" , "jon.grimm@amd.com" , "bharata@amd.com" , "raghavendra.kt@amd.com" , "boris.ostrovsky@oracle.com" , "konrad.wilk@oracle.com" , "jgross@suse.com" , "andrew.cooper3@citrix.com" , "mingo@kernel.org" , "bristot@kernel.org" , "mathieu.desnoyers@efficios.com" , "geert@linux-m68k.org" , "glaubitz@physik.fu-berlin.de" , "anton.ivanov@cambridgegreys.com" , "mattst88@gmail.com" , "krypton@ulrich-teichert.org" , "richard@nod.at" , "mjguzik@gmail.com" , Simon Horman , Julian Anastasov , Alexei Starovoitov , Daniel Borkmann Subject: RE: [RFC PATCH 47/86] rcu: select PREEMPT_RCU if PREEMPT Thread-Topic: [RFC PATCH 47/86] rcu: select PREEMPT_RCU if PREEMPT Thread-Index: AQHaJ7viiNa4TRbbnU+bBE2OROIvJrCb+7JA Date: Wed, 6 Dec 2023 10:08:20 +0000 Message-ID: <267e9e26ce5048d08e347ad8d3438c17@AcuMS.aculab.com> References: <87wmu2ywrk.ffs@tglx> <20231205100114.0bd3c4a2@gandalf.local.home> <1375e409-2593-45e1-b27e-3699c17c47dd@paulmck-laptop> <20231205154518.70d042c3@gandalf.local.home> In-Reply-To: <20231205154518.70d042c3@gandalf.local.home> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 8E73D40013 X-Stat-Signature: 69xume5rqt9numzc71omjdoqf5psabnp X-Rspam-User: X-HE-Tag: 1701857319-848263 X-HE-Meta: U2FsdGVkX1+09JmcqYvS799tY+NY9qetQygDjtMMVNR56/op1KMt4W91uqxJP2vCo1oj+OH4unOcw2xiPqF91xqHePF/eP9Ysw7ysZCJw/ri4JVdHV8V8kKy55jb34QcZX+a7hSRjjxsYrh0QuOM7fR5dm2xWqJSLRPqC0lQEm78b+13iv0v57yioqIo4HoMxe5fgM33+pgPErD3KNQ7fvu6zGSLd/7LAxXFE6NRs4NVbcOWAV3pajHIQqgC9l19cCfV9g6c5vLCfTSIODYx88vM8PP23bd9QdkfoY96IVPxKL+zHSlUtj9o+lrDPuKIt9VhEUo8tnKUVOrHdGHSKmfP26zORt3WYXfdLsAJ4lKVwSrkrnWuLFUGPi9GKuFDLJ2P/4w0T05x0R3FhhK+qGzpXGnZolhtP2KiSzV4/TV1FtgggTUqEzY2mM/lE4/3e8pqr2KNQDClWSNXFHepUCylyzkAnKw2wMFkGS/lehWdX1N7pm1Ykd2gS9JOw7ZdOpyBytA8Y4WMyOyQAbUWIdNbzaobjbXaTIeSBjJMljvdPJiRjh6lwUZgZvghJv36i+lqip6TISOmW4Bc0G1ZFudf0E4XkGL2Vl1Gptq2esLV5vTfYhQecrHo/Awf0HH6oaMGtp5Nxv037dNhA57LEe+5EpTrxymA+TQY26zwjqNCJdW1Zp9WuiQnI5gIPjpX/b79vCperZjbGKRb6ZPKnUl3wFuS0JYpuTZgDhLMLUPMNAoiHSkaK+/71hVJPcSACRyUPrEVjKLZpFkA6y2LVuagtWCn+idZxKMnTL80joTTWkNRPyvjycr0ILBfD1lskL5qR+DHqgTnKYs4S9WVSVTj1Ty5/0rp8+B4vl9s6tsVtMuxSTET1EOhkoRhaw+aCwOdHWM7A+3tWha2ywXsaiVew3Bv1TxtQOinppuxHndzDk7Vvi1tgsN9br0582V5uFgJGOA+AMP1Phwcsd4 Xaef/XC7 Rga0ZSFPtJ0Xpd246cajp8l8BfybhmOrSbO4NyKqRVBkLnl8DQKo1j5fvsrR+VxuWm63sUHoF/zIoX4D/Pu7q43DTACU1cdvGgolaYLGv1pZv4cIZBSufguIC95NEj9jPqWVOPQibGKM87BeqSNNkYfpu4TfC52K/HjGjpB05yPd/tWxTUvcgqS0HNn5NSOo6F1j6ze3Y2E8G6zrB3kc4PgQGoQxD2FQGfyqC4dqgZmu0AHdXGLwOopvvWYBigdPayoYiu71l5/w2XR/uzx+VtDz8JQ== 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: List-Subscribe: List-Unsubscribe: ... > > > One thing I would like to look into with the new work is to have hold= ing a > > > mutex ignore the NEED_RESCHED_LAZY (similar to what is done with spin= lock > > > converted to mutex in the RT kernel). That way you are less likely to= be > > > preempted while holding a mutex. > > > > I like the concept, but those with mutex_lock() of rarely-held mutexes > > in their fastpaths might have workloads that have a contrary opinion. >=20 > I don't understand your above statement. Maybe I wasn't clear with my > statement? The above is more about PREEMPT_FULL, as it currently will > preempt immediately. My above comment is that we can have an option for > PREEMPT_FULL where if the scheduler decided to preempt even in a fast pat= h, > it would at least hold off until there's no mutex held. Who cares if it's= a > fast path when a task needs to give up the CPU for another task? > > What I > worry about is scheduling out while holding a mutex which increases the > chance of that mutex being contended upon. Which does have drastic impact > on performance. Indeed. You really don't want to preempt with a mutex held if it is about to be released. Unfortunately this really required a CBU (Crytal Ball Unit). But I don't think the scheduler timer ticks can be anywhere near frequent enough to do the 'slightly delayed preemption' that seems to being talked about - not without a massive overhead. I can think of two typical uses of a mutex. One is a short code path that doesn't usually sleep, but calls kmalloc() so might do so. That could be quite 'hot' and you wouldn't really want extra 'random' preemption. The other is long paths that are going to wait for IO, any concurrent call is expected to sleep. Extra preemption here probably won't matter. So maybe the software should give the scheduler a hint. Perhaps as a property of the mutex or the acquire request? Or feeding the time the mutex has been held into the mix. It is all a bit like the difference between using spinlock() and spinlock_irqsave() for a lock that will never be held by an ISR. If the lock is ever likely to be contended you (IMHO) really want to use the 'irqsave' version in order to stop the waiting thread spinning for the duration of the ISR (and following softint). There is (probably) little point worrying about IRQ latency, a single readl() to our fpga based PCIe slave will spin a 3GHz cpu for around 3000 clocks - that it is a lot of normal code. I've had terrible problems avoiding the extra pthread_mutex() hold times caused by ISR and softint, they must have the same effect on spin_lock(). =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)