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 C9076C47077 for ; Thu, 11 Jan 2024 12:36:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D8996B006E; Thu, 11 Jan 2024 07:36:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 486DE6B0098; Thu, 11 Jan 2024 07:36:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 300706B009A; Thu, 11 Jan 2024 07:36:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1C9F16B006E for ; Thu, 11 Jan 2024 07:36:09 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E5BA5120540 for ; Thu, 11 Jan 2024 12:36:08 +0000 (UTC) X-FDA: 81666977616.01.660FF66 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) by imf25.hostedemail.com (Postfix) with ESMTP id 32FECA0009 for ; Thu, 11 Jan 2024 12:36:06 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SLwERbM6; spf=none (imf25.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.11) smtp.mailfrom=ak@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704976566; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xRA8RaFNu4Cwx4kYpYDAzrlMhkoYHt6+xOaSNQBOWCc=; b=m5TuVRVslkmR4h9eqE8jOkrxcv+ymrpBPyIkDFUzx8WtXt1sPZ6Xk2xG490PyqTXmgjViy rArbygekrYl1gfJfjN0DbM87/LtD+f85+zaRqYJig+kh2hM6OLrvxJMgvJr9f8sWz83IPE p67dTH/vTQlyClGHMYNBvFzvH9wx6oc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704976566; a=rsa-sha256; cv=none; b=cC13seLmWMQkxk27JcopnCkEiCeaP+HjtduTYdlAJkNR4zw1FXCmyG/aT8KOFgmfGgroGL 5curtZ3J+aNhfA3dK/YJ5sx15tHTHSn4aCGYe9t+fQa0r3WbVs6CdP9rgwgrhWY4UO1t2u vjT2vB0Ues1uOkWX83+CMeBAoGFR5dY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SLwERbM6; spf=none (imf25.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.11) smtp.mailfrom=ak@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704976566; x=1736512566; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=YtXDiIvWUWaP/lYh1Up7SkxhhppURJh5x5MViBxRt1Q=; b=SLwERbM6xnYljFQ8i5rI3Y/o9tHElg9ddBPU41aI9NJI65tCLlBQW7/2 0Fkj/NKxe7Uis7CGlhk7EDTwj0cCWHmixIEQMWe6i0dZ1fex7fAIYnJsO 1yvvuxH7OgaVR2ignzJt+zeJ+3q0A9yVlTVBmdIcpdK3NJdVB0YzX8EOV CLatdkP6rXcnKgSq6GX2DtSOvwT6rvUv+6NHaALFFLuvLmMt0F/TxwY1p caYmT4WQVnprKqKwQ44NgXXZ05iAKzgkijXnXKqr1yPUPYJMxInvxOwd5 qIOMV503ThpCvcfoMkv7rVB7lrCfiAe59O8Kn7gWC1CnFHO7ut2inwJo5 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10949"; a="5561818" X-IronPort-AV: E=Sophos;i="6.04,186,1695711600"; d="scan'208";a="5561818" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2024 04:36:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10949"; a="926000150" X-IronPort-AV: E=Sophos;i="6.04,186,1695711600"; d="scan'208";a="926000150" Received: from tassilo.jf.intel.com (HELO tassilo) ([10.54.38.190]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2024 04:36:04 -0800 Date: Thu, 11 Jan 2024 04:36:02 -0800 From: Andi Kleen To: Marco Elver Cc: Oscar Salvador , andrey.konovalov@linux.dev, Andrew Morton , Andrey Konovalov , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Subject: Re: [PATCH v4 12/22] lib/stackdepot: use read/write lock Message-ID: References: <9f81ffcc4bb422ebb6326a65a770bf1918634cbb.1700502145.git.andreyknvl@google.com> <87sf34lrn3.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 32FECA0009 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: hh7gpm6159rt7hpyj7akw3qu3wcjbqiq X-HE-Tag: 1704976565-997189 X-HE-Meta: U2FsdGVkX18j3FceB9d3HI7HxOhStk78LkRGvVF9hP1DNKKlgSH5mgMhAwbkYnODSEDwXNupdKmR/WQY8TzPKUShQrs37dn5Qg6CiB8e3KxlsIWd+AQyVc1oSJbA2oehuIorOfAuJ1+rsmYcuZtZldo00luOcVh/0i2V5jffKvs332sw515ke5a9nmiTQOGLkZDHrV8iOVfV3Qf3AcOuhrU/IVQLNOz493bXRvP26RKAYwkIv7fTLe0cW4477JP/i9u17fhHoxFIE8mAJ0ygxuHNFiFqSHbNKKmsYpz97EOAdnIGZn7zUz8S+Nk9/s1cBc48Hn9Iixlpa0x1UQK0jGGdmOtOcVLlnbapYZa30j17u1msztDD4jRRquz7YPZPPE6FWtk2sLZvfkPuQDDrczbxSzBYCf3jMAOA07kp5Td0FGJE6dKnSVqwLryAIZDGBupShwYOb9A49wvQxhABsR8jNqgvzRnvHrhO3KI3NR0tSGf8I+rKcLLc3leFRcgCW5qeDq/jZZ8cT3UibD7DuF6kcwIxfqYQD9zMkoUKZsolp9251YVgf+lhqdwL/2ct6/QDavC+TP3Cp/D8jp69/5gwTal1xpVrCqUVciGi1oeg6oBE/9bqmKxEKDgKrbwwLbX8O7/Xe5FiKMCIzjzolcP7Hz2uZQAARvdZrAY+v6+0r1tm/jeDTgNnld/hg4u38bQKbSPk4n6C+3r+vZbb0BuBPw+gWVD0JC2I1mIPNZ65C2oOI6JqawCDT5nuzO1Bwhz9gxF5TRZ2HznQo6vElZfchiffRTSdpxX93gzTSjn2UJO+vWXPt5r9kKxEkTR3UKV2KpsjvH7llY0IKdMhnBnbGMT+A8OsgWgkTlFCnUXUo9nJk7EWhBSFZswRon7fh4PS5lJDEYX1X/elp5/a42pEjJzjngHFY040vpOKRyBsalKCOeqO0b2qp+3wvZ80CAS8RAC4pV/byjuwinY 4w7GFRFs l5H+K+P9IYz+s2WnhxqBtiKxHjoFitVwihQ52+4yMwZoRWQpl8yblzmz9vYTkgS9kXMz2uUYP704BgdfaPOFnRGoe3LXUZuiFmVxDVvf/r4z7+HSwEWsp3AN4NmqE+6Srbc6u 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: > stackdepot is severely limited in what kernel facilities it may use > due to being used by such low level facilities as the allocator > itself. RCU can be done quite low level too (e.g. there is NMI safe RCU) > > I've been suggesting percpu-rwsem here, but looking at it in more > detail that doesn't work because percpu-rwsem wants to sleep, but > stackdepot must work in non-sleepable contexts. :-/ Yes something per CPU would work too I suppose. We used to have big reader spinlocks for this. -Andi