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 7E04AC4167D for ; Thu, 9 Nov 2023 08:38:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 038608002C; Thu, 9 Nov 2023 03:38:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F03798D0073; Thu, 9 Nov 2023 03:38:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA4428002C; Thu, 9 Nov 2023 03:38:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C85A38D0073 for ; Thu, 9 Nov 2023 03:38:48 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1FE9E120D8A for ; Thu, 9 Nov 2023 08:38:47 +0000 (UTC) X-FDA: 81437765094.23.605510E Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by imf01.hostedemail.com (Postfix) with ESMTP id 0CFDC4000E for ; Thu, 9 Nov 2023 08:38:44 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=bootlin.com header.s=gm1 header.b=RhcVrG2F; spf=pass (imf01.hostedemail.com: domain of miquel.raynal@bootlin.com designates 217.70.183.200 as permitted sender) smtp.mailfrom=miquel.raynal@bootlin.com; dmarc=pass (policy=reject) header.from=bootlin.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699519125; a=rsa-sha256; cv=none; b=KaKu3SH4bItCgniMCkem9B4ko15BYsa177a0Wt5L9giJy3q1WcnF4iFcpylJ+cOWMEQpSh /1ClNdtetwxPlWEZd84jKwpRFaVEH5WzzGeJ6F98E50fWmVJvGCQWpD2qKM0QLuJssSu/w PLi2h48eWzoPkdwJajeckuAyBkO9ysg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=bootlin.com header.s=gm1 header.b=RhcVrG2F; spf=pass (imf01.hostedemail.com: domain of miquel.raynal@bootlin.com designates 217.70.183.200 as permitted sender) smtp.mailfrom=miquel.raynal@bootlin.com; dmarc=pass (policy=reject) header.from=bootlin.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699519125; 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:dkim-signature; bh=f4opqU/Z6a24vHtgPOkghLbFyCc/8KcYTc6s60E7F5I=; b=uEHQiT+gVOO8u0m6lqj1CUwD4S5+ihQLaHKcWV1qccI9eKbq+GsZYwCws6hVVWUi/9ayJC vO/MHMAs4fRdCveal3MAhNHoWMxiwOuQAz4NRnVh9RMcvLJqhVftl4X5oHZntnPYNYO2ty YDQMw2rNLH9lSHTGJn7Qo9Es0jCsZHc= Received: by mail.gandi.net (Postfix) with ESMTPSA id D57A820008; Thu, 9 Nov 2023 08:38:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1699519123; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f4opqU/Z6a24vHtgPOkghLbFyCc/8KcYTc6s60E7F5I=; b=RhcVrG2F1Hxfyp+NjKD/SAzO29Nha82Z0erelDshJk08xr+xueghlAuzO3lUE2RC2Tt083 eBLufb6AYsCDlOhMOIHK6MZngWiho/bRhg5rm/Zji43vHvfZMgNuCTgsoUYuBncHUjwY7G lbvaj3h0clGBI7oZSUV7gkTDc1DiqfT3Rl/FiPZXrnsZut7EhUVG8enauZMzs6S/c16GJl QrPr7VJINus08VnVFf6DVT8pujwmVNdNUygZPDqD+ZfbTIMtXIp3SIGltri1rMcklJxS4H sjGVKwXy3VzAmw9WNNiukLm5aqCgmb8ezVf3FgnLkef7zGujkh+Nq3F1wd4Qgw== Date: Thu, 9 Nov 2023 09:38:36 +0100 From: Miquel Raynal To: Steven Rostedt Cc: Matthew Wilcox , Ankur Arora , linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org, torvalds@linux-foundation.org, paulmck@kernel.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, 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, Vignesh Raghavendra , Kyungmin Park , Tudor Ambarus , Pratyush Yadav Subject: Re: [RFC PATCH 82/86] treewide: mtd: remove cond_resched() Message-ID: <20231109093836.42a0e006@xps-13> In-Reply-To: <20231108122116.5e2c11be@gandalf.local.home> References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <20231107230822.371443-1-ankur.a.arora@oracle.com> <20231107230822.371443-26-ankur.a.arora@oracle.com> <20231108172827.1fc0bd89@xps-13> <20231108122116.5e2c11be@gandalf.local.home> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 0CFDC4000E X-Stat-Signature: peytxugrs7q766g3uxnnuj9pjreeckex X-Rspam-User: X-HE-Tag: 1699519124-538475 X-HE-Meta: U2FsdGVkX1+IS5+4hfdlEdb2md2Ly9YyLqh750F724K1vlvXQC5bs8pX67QEcEjj6hegzaWk3LVb7ky+UghCTTOaQ2S+9DvONJvS1q+34BQKXuhnHDejgpTvYoaBiLX5Zy/rNmiJ9+ENF4bPQO4b1KMkdY35Zh57LVaWre6T/ubRRX2nDK+PYWHZnTWbJfRUl7aJRy+yFsfIqtYZko6MzDViiD7A1Tq0qlPzNlWieO5gE3xTru0DqquIur6yo/aewrF6I9wIpmNPn8+sHcAXvcuSQaC13+O22UTZL9Mlwc+P2w2IE5QSlj0UITCMDIrMfzmK4R+3Lgdy0ivqPA+V8DGWVRrBc2s2gG1pX/+uIy4w/qhiCo69HAbolRUm39yVujp07edRBaFL2iZz7zUR/ZhuyvmfiKyd9w/FodvRuOl/+Jodp+KscIwdJYmgT/UwyQoETKVGGzkKaaguf4SQnfHEEzGxJeVE0ypcZvAjDhLR/2qP7P844gSNVtfh8udCMhLKev6in96IEqbj7dyTp98yKVjIlTfUGNyiVuadvzMlYbgBJXomfYV+tzciem/Su5lVRcevMf6SHCXpLHEj/hRcbJHARLknteGmvUFg5pRCV7KE0ol+0BYLFAcSCOUXde+CnAbQeLtziMLpJnHiv9YUpAXfYpPpS4t3pmKRUnzuPUADdhY4VMNwXELWE1pLhf0DapwzClNDXah2smOzHbZJlV68RaVfCVFPgsD1gkRsqkveoPKLnnISvtWI2oDzo92aw2YSs0rAAQw9glFZJdozCqQoua9OG2+ECRr6D2XVkNcCH8k9fZ7/J9YmR9tKO+6C4YFTJ6/i0CcnYCsFG4giiUdQaMdOuFJ+62yk1/3eKidnpJCGk+aKK0zOBOaKCqaPVbPoas2QTUeoqR4MdSIdx9w3mNg8VGd2GMI+zQZ2vNpiHEyjy/5Bbzd5vovSkBIyqw6EDl+8iM1kMBV s8yI+4UD 5DtQL1DzfS7McQDZvNujcy/j7yYIOR8yoUUSbKgqWMxjt9LGK311qDavW0Xp1AHLRm+9q1Te2q1UuQrrgLlb0LnP1Kg+LG28HEhyV1c1vRx7fPVGGTcCnnux0jgZWMGaipakOa1ucow+51FndOdZ4dr5OwEaeZ6MFcSvPUSxQ2F+I4ru9FCvH9zJqB6Dz9QXh+/uf0LI0QOqd8USgnCCMGidR3xq+DeMNd5p3hkcOGEdfzqGiUpdUJgrexGUlMX0R2ED7h6PlOq/VMUDTbmCqJYunqI3Ov3CW8sF4qZcWer+vch/+ZmwmJ0KE/jjRssI7Pb4QoLlQxktkcszx5snlhQG1xPJD6n6UgfIO 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: Hello, rostedt@goodmis.org wrote on Wed, 8 Nov 2023 12:21:16 -0500: > On Wed, 8 Nov 2023 16:32:36 +0000 > Matthew Wilcox wrote: >=20 > > On Wed, Nov 08, 2023 at 05:28:27PM +0100, Miquel Raynal wrote: =20 > > > > --- a/drivers/mtd/nand/raw/nand_legacy.c > > > > +++ b/drivers/mtd/nand/raw/nand_legacy.c > > > > @@ -203,7 +203,13 @@ void nand_wait_ready(struct nand_chip *chip) > > > > do { > > > > if (chip->legacy.dev_ready(chip)) > > > > return; > > > > - cond_resched(); > > > > + /* > > > > + * Use a cond_resched_stall() to avoid spinning in > > > > + * a tight loop. > > > > + * Though, given that the timeout is in milliseconds, > > > > + * maybe this should timeout or event wait? =20 > > >=20 > > > Event waiting is precisely what we do here, with the hardware access > > > which are available in this case. So I believe this part of the comme= nt > > > (in general) is not relevant. Now regarding the timeout I believe it = is > > > closer to the second than the millisecond, so timeout-ing is not > > > relevant either in most cases (talking about mtd/ in general). =20 > >=20 > > I think you've misunderstood what Ankur wrote here. What you're > > currently doing is spinning in a very tight loop. The comment is > > suggesting you might want to msleep(1) or something to avoid burning CPU > > cycles. It'd be even better if the hardware could signal you somehow, > > but I bet it can't. Well, I think I'm aligned with the change and the first sentence in the comment, but not with the second sentence which I find not relevant. Maybe I don't understand what "maybe this should timeout" and Ankur meant "sleeping" there, but for me a timeout is when you bail out with an error. If sleeping is advised, then why not using a more explicit wording? As for hardware events, in this case it is not relevant, as you noticed, so I asked this part of the sentence to be dropped. This is a legacy part of the core but is still part of the core. In general I don't mind treewide changes to be slightly generic and I will not be bothered too much with the device drivers changes, but the core is more important to my eyes. > Oh how I wish we could bring back the old PREEMPT_RT cpu_chill()... >=20 > #define cpu_chill() msleep(1) :') Thanks, Miqu=C3=A8l