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 567E7E7717F for ; Thu, 12 Dec 2024 16:00:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B82BA6B0082; Thu, 12 Dec 2024 11:00:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AE2A36B0085; Thu, 12 Dec 2024 11:00:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 936186B0088; Thu, 12 Dec 2024 11:00:16 -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 73B586B0082 for ; Thu, 12 Dec 2024 11:00:16 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1B3E61401FE for ; Thu, 12 Dec 2024 16:00:16 +0000 (UTC) X-FDA: 82886767698.08.4B5634E Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 396BE4000A for ; Thu, 12 Dec 2024 15:59:44 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=zDCmuVT8; dkim=pass header.d=linutronix.de header.s=2020e header.b=PfpVSuwg; spf=pass (imf07.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734019188; 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=ICJ+S+1qM6mvzE1JgOHP9eIvy65HW0ixwHu8nwlDaGw=; b=nU1OaANYkCfuzRRheUsJVNgGhBQKMPk/M5TwKruqLSDkezDnpqQ5Z8R8WDVKT7tdQEo63u En4X+PSRWubhNOxfSvPfwXEUWIstf3Zo1yIhfrCCa/CMtptHTkrkq+TPh5bmHMaWP4o53n jzTWIQXQNWn4+9tHXNVbJ/WZ+nQUU/0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=zDCmuVT8; dkim=pass header.d=linutronix.de header.s=2020e header.b=PfpVSuwg; spf=pass (imf07.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734019188; a=rsa-sha256; cv=none; b=m6tJ/dEzXlcZ2qINZUrREhnRbsWu4zWY0B9kdB+XQQclemPgi3tFGvX9B2LjxZ2PbklJ9V 37dhcxO+L9GoK32wp3Se7dIfESpl57VvDSb2/M9kI91LaS59h+G0pCW3qKqY0g8QD8uQQw VXLiV6ZB4SfR3Wtyw/x97N0BOiooiYE= Date: Thu, 12 Dec 2024 17:00:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1734019211; 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=ICJ+S+1qM6mvzE1JgOHP9eIvy65HW0ixwHu8nwlDaGw=; b=zDCmuVT8/UT/IrU94t9gYBsobMNwPcF2i0hWDsl30ECnZtAxiB7keIuH6AdntoBKkpJz8G zPju/ybt8amr7zrgXNRBMT2jI1zSd0OnafdrfhEGKnLmnRymmJ7xzFxSWJXWXPAmmz9REn ixUGOJav30VMEjYrp81/6siIqJd+bijJq4Z5NHdQfYTh6QNkWXWlaZ+LSBxy/o8v4Uk91y 2bnyGCU1pt9PWPtW8B7S8tEpZpxMalpYabzKZSl3InKVlW5imo1jnGpMs7LQHYUdEF0bYd t/iVHGo4osClkantGT0vd6uITBM3b/b39o7W/JLZkmngvgzIi4ohvYzy371NVQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1734019211; 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=ICJ+S+1qM6mvzE1JgOHP9eIvy65HW0ixwHu8nwlDaGw=; b=PfpVSuwgHv1e0r+1UiUxh2mx2ck7r8dlJePxZAhnaplekTYqDrvFB5nI9+7x1t//Ub3UQU k+sh1fPmFK2HwfDw== From: Sebastian Sewior To: Steven Rostedt Cc: Michal Hocko , Alexei Starovoitov , Matthew Wilcox , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Vlastimil Babka , Hou Tao , Johannes Weiner , shakeel.butt@linux.dev, Thomas Gleixner , Tejun Heo , linux-mm , Kernel Team Subject: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation Message-ID: <20241212160009.O3lGzN95@linutronix.de> References: <20241210023936.46871-1-alexei.starovoitov@gmail.com> <20241210023936.46871-2-alexei.starovoitov@gmail.com> <20241212150744.dVyycFUJ@linutronix.de> <20241212153506.dT1MvukO@linutronix.de> <20241212104809.1c6cb0a1@batman.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20241212104809.1c6cb0a1@batman.local.home> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 396BE4000A X-Rspam-User: X-Stat-Signature: fx1x3gro67b9dnhxfwzdhminta6psge6 X-HE-Tag: 1734019184-981331 X-HE-Meta: U2FsdGVkX19ZgvewNE8GqNHhZXVvS/FlvCjxEwzdV6HQeEzSLy00Dh+fT3dA6OIVvgtZdowaPyJGaNXSU9HEJHTBrHs+JZ/H+Fcby1DRTzKcMRL0EjImX9wlL6Um3G8rD8pDQCniu0bZgUd3PCb03P6HLrWrUlxDLQmZFWtZdROhJDHzYtdOuiyUh5uMeuYbVrVHMjywCv9rySkaeTSPHyqceL8XfMbSJRLMzcewoYqkznMwhwHY3t/SuCGX7qEflX/ko8ASYpivUioHC8fnTYC4ShBQkO2vWCE6jpceMgD9odV1ARnjM7gsxPBb9hRO/2UyZ9i8qEZnlNEIF1c6OAhoZmEscuFG7ZdWEW/qsswzgOTPCh0UgTNavkA9q0ETSmLFO+/eke0upppoi4CTZC+pZKA+SCzUlZqeTGpR1D+8zIksXvZ+fWIRUqaJWJNDZQXFb+nMQ7EK5y33O4veVS7Daq48NSO6QkmXM6z/tTbYZ/RdjsYtuG0lM0CpPEev2FssSbpw88Y7i5l7cpacePJAI5Gg8TtCZ/PFXUUzOPKgkC5BWSVrlTESKrp8l+w1W62QOVcvaWPYl77+TmkDx6P068BcEp51vVG41r0sEgZz2FeBz1c/C8hnIptPKO1hOjpGmhugJ/9I6RHT9OjGhY6wOJbk4g/en3TXhbUS/I/+W02TNcSFkSMrF5ks24wBgNwQGJ3v3/Xnt4OqYxMaPypmrmdrnVp1Fs4yhGzl8HBhQDPM4QH/GE99oFP9Z1GaMiGzIdvWhkgE7KETbB18ZdelP2dIUV91ZFKXjLzL+fQtGnDTXqdbvtZzs5TS8gR7sZCCEy/3MHLq12H450hj6CA3epM6aqY7wwJ5h8xBlGX2m65PezpO3xn0Ubzw4IOIQmB26YaS5x+UWFh//jsl2RPbn8pegd0WgEQPrb71Eq/32flwHmEKmrhEaw0mk0hli4E+p65Si7jB+0tm46d OMT4yO8X pnpV69ut+1tUTZlVu8wBsZqMWcSoqxtRicSFoYViB4IjckOSRT08QScaMF2wBHtpiT3/ZoI1c0+TMQKqzb2d2l0tjvztS0QfDGp6baN0QGKVNazm6kAREdhKcMAZHba6vmPQ7XiiNkb/QkaT2PWOsI2MYzH+PYCruwJVBb5FF0w4oaunGmxcwmAJXZFgyvtBBPyoHYFS4ukktC92K65TcVLmQyU2DkBWLdJeFiVfbgcZBuh0H6XvvJ0r+xdbdPxDFYf4dPAmDug2Iewlc84inEhQrLg== 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 2024-12-12 10:48:09 [-0500], Steven Rostedt wrote: > On Thu, 12 Dec 2024 16:35:06 +0100 > Sebastian Sewior wrote: >=20 > > If NMI is one of the possible calling contexts, yes. > >=20 > > One thing I am not 100% sure about is how "good" a spinlock_t trylock is > > if attempted from hardirq (on PREEMPT_RT). Obtaining the lock und > > unlocking is doable. The lock part will assign the "current" task as the > > task that owns the lock now. This task is just randomly on the CPU while > > the hardirq triggered. The regular spin_lock() will see this random task > > as the owner and might PI-boost it. This could work=E2=80=A6 >=20 > Looking at the unlock code, it and the slowtrylock() appears to use > raw_spin_lock_irqsave(). Hence it expects that it can be called from > irq disabled context. If it can be used in interrupt disabled context, > I don't see why it wouldn't work in actual interrupt context. trylock records current as owner. This task did not attempt to acquire the lock. The lock part will might PI-boost it via task_blocks_on_rt_mutex() - this random task. That task might already wait on one lock and now this gets added to the mix. This could be okay since a task can own multiple locks, wait on one and get PI boosted on any of those at any time. However, we never used that way. The lockig of the raw_spinlock_t has irqsave. Correct. But not because it expects to be called in interrupt disabled context or an actual interrupt. It was _irq() but got changed because it is used in the early init code and would unconditionally enable interrupts which should remain disabled. > -- Steve Sebastian