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 8255CC4167B for ; Tue, 5 Dec 2023 01:04:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20AD46B0085; Mon, 4 Dec 2023 20:04:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BAAF6B0089; Mon, 4 Dec 2023 20:04:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05BB36B009F; Mon, 4 Dec 2023 20:04:02 -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 E286B6B0085 for ; Mon, 4 Dec 2023 20:04:01 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C0B1640474 for ; Tue, 5 Dec 2023 01:04:01 +0000 (UTC) X-FDA: 81530967882.07.6BDD5D2 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf22.hostedemail.com (Postfix) with ESMTP id 71863C000A for ; Tue, 5 Dec 2023 01:03:59 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FL4NuMjy; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of "SRS0=7QCX=HQ=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=7QCX=HQ=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701738240; h=from:from:sender:reply-to: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2F6oYrzx0QWGqJt/iP5MUcXqDVZI2ZY9X0N2ftYuqsI=; b=p/dpcMs+tvj7gE3+KAa9IeWnxCMOkNZuUZ5GxQns3ZMvYd6BfK/5Ioow+Qe6yam6qw/pVJ 2RwEx6TV0VHpsM7N6UO/2LAiBXm7S9ax5P6hHGiHbJvB9a8lh9Of2TRFUVBiUs3zgppe/b uk2p7okZQeOivvKeTAoKKQfdJkGh1MA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FL4NuMjy; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf22.hostedemail.com: domain of "SRS0=7QCX=HQ=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=7QCX=HQ=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701738240; a=rsa-sha256; cv=none; b=N6UnnD5T05EIEzmvzYZUp92yBTAi3AlFAnU3Ofv+ZMTz/RAat1UdwSgsdzF6RmORZcNBkx VV2OgNhjL0wrl9jC2JpsWIS22Vs/4Wmn3FuUHjhNOm3ZvHUTUWLdbLEwZ/DOc+P6sbvXKB w+Ua2PEXzdW0uBU2rvYQU85tu7uUdwA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 83E9ACE13B0; Tue, 5 Dec 2023 01:03:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE6F1C433C7; Tue, 5 Dec 2023 01:03:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701738235; bh=Bs9k/6LoUODYcT83sb8TNsFZmO2JrEzRWlVXH0bC4/8=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=FL4NuMjyUEvhEfw6zbKZYj5RExoInuV0ePirGfgE7E7M4QrqD+0xVK1990Nx5iEFe 7nMA6P03QxPN6J7poviGPulyznm4U6sYJ8Z7IIkiR3aYz4SpgWssQgaBp9PfRqFddh e+7F+a7pDXD9mqMIvmLt6ndZBIPnOTjlLbqeN5R+RsAN19JgHxi9eMN7wCgJayN72z S2+hAutD5D6aM51vYrj/7m5iqsZE4WdoImSPurfZ9dKrz1iq83m9KHbn9t6IPRr7VF P/6Bku8Qy3k7I5J7MaLPL5QD1kVNoDeMsipKuKi8UNJYjFYtsYPiYK/Oz1l8gvAuSj CuH9XQ/wmz7Kw== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 44B48CE1147; Mon, 4 Dec 2023 17:03:55 -0800 (PST) Date: Mon, 4 Dec 2023 17:03:55 -0800 From: "Paul E. McKenney" To: Ankur Arora Cc: Thomas Gleixner , Steven Rostedt , 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, David.Laight@aculab.com, 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 Message-ID: Reply-To: paulmck@kernel.org References: <87wmu2ywrk.ffs@tglx> <87plztvig2.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87plztvig2.fsf@oracle.com> X-Rspamd-Queue-Id: 71863C000A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: bau1onapuprd7qbox14okeod5kbeh6c8 X-HE-Tag: 1701738239-86383 X-HE-Meta: U2FsdGVkX1+2TdQnNhRqws88W8GrqWLjLh+9NZ1iIZp6iZjRI6E6jqBfNHW7uJTXL7MIMBMSeg4iaWU8+nl3kykpHn5+PwMU/qfsDSTNVB2+aoZDkR8XH9PDqtLWfVurbiEJMqy/gXpK+Rb2O9uCcYQ8BlMQxtC5uZy7312dfFCU0clHzM/1NcDxpnpmFrtaEhLXLmPn/J4I53JvHLbJ6Jz9UiPOLVyzMPg1dpbf2vKB3A78foqdID1qM6iWtKIVOl7VOLNERMY6GCgsL9CAyV9O2/qXbZbbKMrtlWhXtv6d6/NaVzSC6ei1qdx8W9kt6iOuoQg4JktoH0jUs/wtatwp9C9EMWrM8ItWF9twJp1f23K+LlHpxvayP6DGt7/WNcLoUjegNbGcYP8JDNkZ2gxkrWmc1be2Fm+ZLqAuoCMxZXPcZReHtgd+j4mp0BP/3eyYFOc2kcHQ+ZxJ+VQFj9I5wzdRbAjPimPThQGW9TunodG+LldMJ1Tz9min1CISnVwdb1nlMIATxU0Sz6zCzMeEY6fow1jKS3uOpZ2qYwm6ppR4sBk85OjSpSvEcl5GQdRHuLcZEZBTqyir1m3kYk9SLTY91fl+yNmAO5lS7NV+RWPQ7kklW9xg+wM6BR+MVwSF/z261xF1SsMtehG/J8ltEh2JAhTI1RSnLBXoojYe4HAZh9QEWDTvptjLvbCmBqjNvb5i7SuSXs8nopDriM8jiWHDxISLG+TfbEx+OeWl0oLDILit6WA0VXWLvhaWS3WF2dRWIbN5jIeiw53JaG3WMvSsyAxK1OtUKCVzr52Vf+Aru1nCBIcWELZLNCLvMWvTWEIfEgxtPEpnNinkbignBlHf/tp7AOyV3CuYPc02xpZZUejM63iVWBlzFc88dO88TJa27nfZfjvbfogqyfdw8wOwX0aCFSTwl5zYlqNUusI3devXMOsKiJpUa1GlTbAdnVM4m/xN1DeEdr8 nv4brpQa snjGn79G8ZXsdkl53cED55fo25XrSNb9cYWGnyQ15VTljfEApcd+P1QJxc3wBr/Ku8r2dvPGyZvYRtEkJSSsMLfes63UWsBkth6f8OVxW3zWJAlD0wEChXrzcM+FjN8oduwsXRvpzuzQ2X4ud3KcjrALSfQZYTIovEHfnL0WhSn6qdKWdXmdKFoI+UbaWEIqjQ9RxA4rTiHjBzV6TdDNUHH9zb86NxUG2R9YD1Tcc0W3cfPJLqvrw6V7iiqCTXj/dRZLudcIMz/mkcKREapuP4VsXEpES6r4l3pjqKFW482idhWPVvZzRg1rbHzQZFeiOTWVJwGMoMGOg7DZt3NaccngY59S20UaBx9naMIE22nK6nz/vn7EUbEKTdFSNW8kLrQntogYYuDijp7Mk0jA+vp5LwgDEgbsd90NnBGVo9JKAGcxj+5QNaOMOJfUZkWJ+OMkBOqZMqp5q7z2cdkb7KeC0Wb6aEM+mvN64AEsGFeMtPwiuFshS8A0APZbcNk/Nygl5RIS3SZBBMMHPC2i00lI9zFF+VMAODnWjztRtY1VYFrUVg84a4ekmjSOBD2BWT+Z9Y9lDMZjA05qGM5HLiq9vz0iCgG2MrUrBHP1V817nfbhld/dbED8x2l8MTIcamFYhK2m8b1sifKNJ4wZmCKjN1u5CwIcvm8T65L8kCG0/GzlZteoV3OI0a3+SQWm0C80XETWZAAogxbzdSx0u3bGrq7PjpZCkQiw8 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: On Tue, Nov 28, 2023 at 10:30:53AM -0800, Ankur Arora wrote: > > Thomas Gleixner writes: > > > Paul! > > > > On Tue, Nov 21 2023 at 07:19, Paul E. McKenney wrote: > >> On Tue, Nov 21, 2023 at 10:00:59AM -0500, Steven Rostedt wrote: > >>> Right now, the use of cond_resched() is basically a whack-a-mole game where > >>> we need to whack all the mole loops with the cond_resched() hammer. As > >>> Thomas said, this is backwards. It makes more sense to just not preempt in > >>> areas that can cause pain (like holding a mutex or in an RCU critical > >>> section), but still have the general kernel be fully preemptable. > >> > >> Which is quite true, but that whack-a-mole game can be ended without > >> getting rid of build-time selection of the preemption model. Also, > >> that whack-a-mole game can be ended without eliminating all calls to > >> cond_resched(). > > > > Which calls to cond_resched() should not be eliminated? > > > > They all suck and keeping some of them is just counterproductive as > > again people will sprinkle them all over the place for the very wrong > > reasons. > > And, as Thomas alludes to here, cond_resched() is not always cost free. > Needing to call cond_resched() forces us to restructure hot paths in > ways that results in worse performance/complex code. > > One example is clear_huge_page(), where removing the need to call > cond_resched() every once in a while allows the processor to optimize > differently. > > *Milan* mm/clear_huge_page x86/clear_huge_page change > (GB/s) (GB/s) > > pg-sz=2MB 14.55 19.29 +32.5% > pg-sz=1GB 19.34 49.60 +156.4% > > (See https://lore.kernel.org/all/20230830184958.2333078-1-ankur.a.arora@oracle.com/) > > And, that's one of the simpler examples from mm. We do this kind of arbitrary > batching all over the place. > > Or see the filemap_read() example that Linus gives here: > https://lore.kernel.org/lkml/CAHk-=whpYjm_AizQij6XEfTd7xvGjrVCx5gzHcHm=2Xijt+Kyg@mail.gmail.com/#t I already agree that some cond_resched() calls can cause difficulties. But that is not the same as proving that they *all* should be removed. Thanx, Paul