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 461D9E7717D for ; Thu, 12 Dec 2024 02:49:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 928FB6B0093; Wed, 11 Dec 2024 21:49:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D8846B0096; Wed, 11 Dec 2024 21:49:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7524E6B0098; Wed, 11 Dec 2024 21:49:43 -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 5372F6B0093 for ; Wed, 11 Dec 2024 21:49:43 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D77B31C887D for ; Thu, 12 Dec 2024 02:49:42 +0000 (UTC) X-FDA: 82884776352.02.AE148DB Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by imf23.hostedemail.com (Postfix) with ESMTP id 2ABDB14000A for ; Thu, 12 Dec 2024 02:49:24 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XeAGipSU; spf=pass (imf23.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.51 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733971770; 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=Ca8OIYO0+FSLXAgUGro2sDxj5RgcMXkMj04Ise63hr4=; b=DJJDAlYnAZAD1zeTBEGQUmRbDGEZpYbPrEu4fWNG4kIhaYJQPz4JVNFLyUG1IjPRzeXf+N OJe70Eq9UwR6ldelmovA+lq+cZwbmMtWYaGf0mcr0YLdNaNMAGeSxLNyer42jqB4AHw/HC xPFuKTl4azpNzpYbZ8/5cX9G3Bw5618= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XeAGipSU; spf=pass (imf23.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.51 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733971770; a=rsa-sha256; cv=none; b=yWsveaGoD41XJhykkpGVLSYMiagQU96CLnUP2OYxk3Q0yrkYH85jwjeag796tz6ZTmeKpr y9RbFf50aEsnPbS8hKLXETCwnCe7zoaIOr8rrrQlIGCJpfdeHk5yJ+ZZNiuxiWqmnfgMMf qxkb7pFo8gIO56UOB2UoeVIro6qgj2M= Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-3862b364538so52715f8f.1 for ; Wed, 11 Dec 2024 18:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733971779; x=1734576579; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ca8OIYO0+FSLXAgUGro2sDxj5RgcMXkMj04Ise63hr4=; b=XeAGipSUGSa5qIf8nbKid6wVCMnphQLQNOhdxLx5McsoiOvYm4cuCV2InwVgzP4pdL +IduFh01Ss3CdvAYrLLZ8Gdru4hJCP6Iyjo+huCoSH97YqQUJwjNRoGuoGUEvhAU85sg JQ43KQzqwJwEi14Ahw2htopWEhcTYVJwpl/YOPx6yCbnAk41clRAYOBLXZdhboQy9Dw8 ObG4nBxqITIF3DMfK8AMf6CiV2WdUXf2d2dDCBbCSemudyld0JU+uzkhydrRBrSGXDzj N1Txv+3BrlyiyyIFXg/4Gj2n9VPwViZVGff7VJ4unuwk3cgOET4QyV+qmKFcMlEvI3UL nbLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733971779; x=1734576579; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ca8OIYO0+FSLXAgUGro2sDxj5RgcMXkMj04Ise63hr4=; b=Lx3V/rUF5Gr+FDz5o4+Dty7ounRN1mGdUR4Xr/DdBG61ZnFOpWZaTbORUBPWmUvpi2 1PGmV9r8a+ycaOwf9j2yz9sLnJr7i38UBbqiCP/cWB+um9iQxfSUonhklq7v3M54mFR6 hlwskuh5zo9hWjxIyUHXkWUFiEfcVmCL4PylgFOtVYwD/+U5oRX7l73oIvMY+zB+HJlN 0Pj+bXuMShrv+rd3XpIC/meZ8tTgRAV53aePzNKOLFhd2r5vKRnf42hEssiRSAWKPPg6 b3lwJ7D+wuuCUTyH5gYqhlXCcl8K/9W7DlLLY0leDBEwxDaLaYWTkErrEatIFGAiR5hf L4xw== X-Forwarded-Encrypted: i=1; AJvYcCVoGbvpvj1m9jbTb9SK7z80dxcWr1VoxIUGWMVcJyD71MeGWAwLUXu3uCzuaQRHQWbKcWzj23IItQ==@kvack.org X-Gm-Message-State: AOJu0Yz+Vc4mVak5NG3jNQ04QAK7gnS0+0/rFJ+7TJKLWwLYPXSlglRa OPHK1t2JLBNhN23Qyt07x/Xp24DG3AkzNSHYsRzBtlXxn1jbneHG9pzZPRgUjgbwKRPk/DOUDHr fL0EseWjIiYYkgE0yxYZO4RBvLBw= X-Gm-Gg: ASbGnctjqMf8fio2HL5UyIX52bnUx4fGHd9Ikj/kgKnvED8xd0Q4xwp2wn8CjGeKTEs vA3x9K9KAFH2foxpd9irpEHLWIb9aDSErukdGyhbI6tU0MYFG2jKzhg== X-Google-Smtp-Source: AGHT+IFP/H5kWKEKUgpAjEJiXLREvhvKzOTx05dqLUwJKirYPA9qWNJlHiu/CRMGLNAneMlTFVnYuD3O/x8WFJOQ2ow= X-Received: by 2002:a05:6000:1543:b0:386:2e8c:e26d with SMTP id ffacd0b85a97d-3878840808emr1065650f8f.0.1733971779204; Wed, 11 Dec 2024 18:49:39 -0800 (PST) MIME-Version: 1.0 References: <20241210023936.46871-1-alexei.starovoitov@gmail.com> <20241210023936.46871-4-alexei.starovoitov@gmail.com> <1c760bf1-14a4-42e4-a55b-438a29987aef@suse.cz> <9e5bdef1-a692-47d5-82b9-96a4f2c68463@suse.cz> In-Reply-To: <9e5bdef1-a692-47d5-82b9-96a4f2c68463@suse.cz> From: Alexei Starovoitov Date: Wed, 11 Dec 2024 18:49:28 -0800 Message-ID: Subject: Re: [PATCH bpf-next v2 3/6] locking/local_lock: Introduce local_trylock_irqsave() To: Vlastimil Babka Cc: bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Sebastian Sewior , Steven Rostedt , Hou Tao , Johannes Weiner , shakeel.butt@linux.dev, Michal Hocko , Matthew Wilcox , Thomas Gleixner , Tejun Heo , linux-mm , Kernel Team , Jann Horn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2ABDB14000A X-Stat-Signature: nnincbdic97g7pcmhxuz8a3ywuqepo39 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1733971764-696847 X-HE-Meta: U2FsdGVkX184izW0x9jRysjK36+8q01uDWXE12Xl+tMTX+x3uwHBHs8/G0lp0cpJFTTUpzCUG882tL3Y0iAnjHYkyQ3s0ZYaSC7IplWG4XeWcyw/6Axekoi+JGmRg+4h24LLmyAWoFazEEW+bc8y3hTlXwIddryWYQixSxAJy5cm5/FRSwVk38AtHcJQR094NogFrvOUXeeSpI+l74HPCy0JMA8yengtcLXYYiADMEDIhJfUdo87vid7G8dYhsZjcGE6KRIqbsNVzn1tzQFD1O/vKI3bD3HlPX0bekTf7Ywl4tBoM+d85drvZ6fmsokXQcNtW7FbBI3e2jojhpK3B0RJnL9yslBn7lA6NVd9zfl0jIwWFO/EE7ahVgj72FckZOtU5cdTUbUrF8UuaJJJ+P/hDhXNfrRaRo9ReMX4x5ElRHMpYxN99DpD99g8LgZR5RQj2BeyRBifWTKmR1N4S94rB0J2svdpz5Rg7dheMqrdlR12X/TPIsvG7GVAAxU49L+/jUKG63iiH7gIYYvEW18fdcZarlcSX3fAf1o/KRcsL6rRkrrOmd5n7vyv0JQTRaajo88rXLW063NAW19HwdRPU+I09wDrNAsYxYZk3OUvjRt940WQkyOF6YE0GPOw/h6+3qRhmFxKQo6k6r1TBs/zjkcVLC5BnflCo52Ojxh46IaI6aX/SA4KUBOZNx/tS9BzDJv8IY0SgI2lt1aEHqbRsah0wuqSXArlAvLA3NDMyxPB0ZVof6J3N8Q8HduJdk+S0+l0gd0yyX4rWb2AR6UxrYj3s2JZJH29iqcsGxSDhIAZJRQx9cZ/go4D4HCQkGbdxnf53HZQVgNn9S7pBpPDqXm3xqy0Ot/PY/4RmDHftaBthe+dlns85vGgcjdXXJZh1ENl/QIZAVN+oMasO5yfAWyc06fe8T8O1u9SRqBthJormajDR+M0YlRN3Evw1qKI9BpShbbGlxlkkmh FW1QjQMQ dj+GAHe+b8arA9e/MlHMqLazpCRemEyIcIj+nN6YV/+VIGJ2QY7B5jBo9Hejq9VL6yipGKopeGDh2e2Nruk96CIUTXy8/lvTyxZ6cXJTefnKFr7kyp9P2nqup+o5ydh3Y5R39GeYyI0nlcsNspRFyJHGMh/0AaLKQAaYiQwsgECfdh9YJlxdyF2MKR9sY+8x9PLiMwBA7kLDUSMTbMc3/ZAoseGgkpHySio8GtmCg+MQ+Z/QL/eHUafhcdgXFdhm+YlcnofWQYFUPKDq+9IEWe9fYxudJmVDEuQfP1AYdzFPAR7Ct4O7mjiGmj31AC1OXxbgE79R0kRpYTKWpXCi5h26AYCaFQqaUEKAbK94Ua6U715i3b8lIFsNmkuENj/S4J2l8oFSGo3AmFpJzwr7my9Uc2sAoDSeRClGoGFMeGOEJyCWPgcWYCAQpaFvfr/5OApX6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 Wed, Dec 11, 2024 at 3:55=E2=80=AFAM Vlastimil Babka wr= ote: > > On 12/11/24 11:53, Vlastimil Babka wrote: > > On 12/10/24 03:39, Alexei Starovoitov wrote: > >> From: Alexei Starovoitov > >> > >> Similar to local_lock_irqsave() introduce local_trylock_irqsave(). > >> It uses spin_trylock in PREEMPT_RT and always succeeds when !RT. > > > > Hmm but is that correct to always succeed? If we're in an nmi, we might= be > > preempting an existing local_(try)lock_irqsave() critical section becau= se > > disabling irqs doesn't stop NMI's, right? > > So unless I'm missing something, it would need to be a new kind of local > lock to support this trylock operation on !RT? Ohh. Correct. Forgot about nmi interrupting local_lock_irqsave region in !R= T. > Perhaps based on the same > principle of a simple active/locked flag that I tried in my sheaves RFC? = [1] > There could be also the advantage that if all (potentially) irq contexts > (not just nmi) used trylock, it would be sufficient to disable preeemptio= n > and not interrupts, which is cheaper. I don't think it's the case. pushf was slow on old x86. According to https://www.agner.org/optimize/instruction_tables.pdf it's 3 uops on skylake. That could be faster than preempt_disable (incl %gs:addr) which is 3-4 uops assuming cache hit. > The RT variant could work as you proposed here, that was wrong in my RFC = as > you already pointed out when we discussed v1 of this series. > > [1] > https://lore.kernel.org/all/20241112-slub-percpu-caches-v1-5-ddc0bdc27e05= @suse.cz/ I like your +struct local_tryirq_lock approach, but let's put it in local_lock.h ? and it probably needs local_inc_return() instead of READ/WRITE_ONCE. With irq and nmis it's racy. In the meantime I think I will fix below: > >> +#define __local_trylock_irqsave(lock, flags) \ > >> + ({ \ > >> + local_irq_save(flags); \ > >> + local_trylock_acquire(this_cpu_ptr(lock)); \ > >> + 1; \ > >> + }) as #define __local_trylock_irqsave(lock, flags) \ ({ \ local_irq_save(flags); \ local_trylock_acquire(this_cpu_ptr(lock)); \ !in_nmi(); \ }) I think that's good enough for memcg patch 4 and doesn't grow local_lock_t on !RT. We can introduce typedef struct { int count; #ifdef CONFIG_DEBUG_LOCK_ALLOC struct lockdep_map dep_map; struct task_struct *owner; #endif } local_trylock_t; and the whole set of local_trylock_lock, local_trylock_unlock,... But that's quite a bit of code. Feels a bit overkill for memcg patch 4. At this point it feels that adding 'int count' to existing local_lock_t is cleaner.