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 BD11FD68BF0 for ; Sat, 16 Nov 2024 21:34:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C5139C001A; Sat, 16 Nov 2024 16:34:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 34DC99C0018; Sat, 16 Nov 2024 16:34:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C7B09C001A; Sat, 16 Nov 2024 16:34:33 -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 F010C9C0018 for ; Sat, 16 Nov 2024 16:34:32 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 72773A16CD for ; Sat, 16 Nov 2024 21:34:32 +0000 (UTC) X-FDA: 82793259990.03.D8317AC Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf05.hostedemail.com (Postfix) with ESMTP id C0EF5100008 for ; Sat, 16 Nov 2024 21:33:01 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q9L9XgJd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731792689; a=rsa-sha256; cv=none; b=hFQZMEG5RaJ0AfHecjoYNjkHWvrV2NsupUxFfd4R/RDi9bztYeJNLa8bHFJntF51NXhV7k gaF5JdfxzxkwK5k6+TFyWAs1/Rlmok7hU76PcXo/Y0TfQwfXM7R6un/9rJ2qBoFP6qAbyE h75LZ9ZPCDejYvdoWy3QS9Yvm1CrsL8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q9L9XgJd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731792689; 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=sSikF8kTZVqo0PltnA0NXuXcsMGyeUDdT1Gn0MQ2piI=; b=co+10WckxHlrB/eS6H9jrIVQSUuPYGSJvSljTHReGkdPWD9htxMoKCXbQqMFO3PSvjVKsx qwFCcNMd6D5L5T0hoKxmXOjwNESq6v1B+AkoC6AQqfNGgfC7+Zb0GrgeS/AYlAO9fnUHka oq61TCYuCLBJrsmV/Qz43OTvTkrnmwE= Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-3822ba3cdbcso1027117f8f.0 for ; Sat, 16 Nov 2024 13:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731792869; x=1732397669; 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=sSikF8kTZVqo0PltnA0NXuXcsMGyeUDdT1Gn0MQ2piI=; b=Q9L9XgJdxlhxpldvx7vxEY1/H0nwVxx5RpSWefh2JFMIN3DOW3al8hApSQ7vV9sixm rjD1MUkEqWMrnOgPhThzZXh1H+wEcrIRTvun6s7a7UL6Wa1wbLovxRUlLqNUgxEz0m0G KKvCFVEQu8haK+IICamsNIGyL7OvXZ1zy3avCRKtJmJwQJu8IUEm41EnnJgWk8jOHWYM Rollg7y8+bqGj1YS2kKD/yQDPaCRxna1GFFq6JUeC1TdPDJa1mFCnGZ7eEQaOuru48Mz HKEvGfC5mx8tgi3v3lKq4/O/+uptqYh1oPvhheQqHNbEWj90fCA7AKNGL0m4kS1tQaEO APHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731792869; x=1732397669; 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=sSikF8kTZVqo0PltnA0NXuXcsMGyeUDdT1Gn0MQ2piI=; b=XolrlWm/fxqfMLE/m2c4mQvLB6rm8zU0kZAY4NSwNvz3XzHHc+ImQMTmpvFmd2EJ7x oMVAeRPxXVoOT+Ru7bgJcqU6KByAwv/1Cyh2hQaeYZ85u+o4pin52ardkTYeybSGm0UL RwgXhXr6RtQBYYDQivVJUpPNlf0niLuIaUruhw5dyhl6XckcaJUbQaPWsmH1XMpDDESh wglowfPT+U574PX2/SI7HKWpgoJznV+ZR7tFOEyjE1m61lyJRGJJOmxiXT4AnPyhbD0T CCH5OXM7RFFQAtbwtEdeMjJ1qGf31iyAOgTrj5E844ggUYMlV9ZAfwewqu6ZEUZvtBP6 YYaQ== X-Forwarded-Encrypted: i=1; AJvYcCV974Nugtz22gUEWkwv0LOalIkGIa1FFhiLjYBam5mMUa9mG4prUTfJddLIKv5E2w9Etdv3nN9zAw==@kvack.org X-Gm-Message-State: AOJu0YwuWGMLVD56JUUNrpJDwpg11um3ODAWLXONgn7M3YNGJUdlCYD+ CN3aUuu8wOszO2vHZrRx6HNIAcimPkSd7TgB8HxzhuG5T1ysnwFQN52WDrKgqvqklvKetSNwQ5x D3w5ErQXjZN1xJskILwjODIBR654= X-Google-Smtp-Source: AGHT+IG+Ts2IjAlnFRPHX8erR0J0YZ7QA9fpp+4BGLy4zsOCrGUeX9sVxLRA+HVK+6DyZDigTZFTkPw50Z9r+OEMBg8= X-Received: by 2002:a05:6000:1f88:b0:37c:d276:f04 with SMTP id ffacd0b85a97d-38225a915fbmr5125413f8f.45.1731792868949; Sat, 16 Nov 2024 13:34:28 -0800 (PST) MIME-Version: 1.0 References: <20241116014854.55141-1-alexei.starovoitov@gmail.com> <20241116194202.GR22801@noisy.programming.kicks-ass.net> In-Reply-To: From: Alexei Starovoitov Date: Sat, 16 Nov 2024 13:34:17 -0800 Message-ID: Subject: Re: [PATCH bpf-next 1/2] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation To: Peter Zijlstra Cc: bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Vlastimil Babka , Hou Tao , Johannes Weiner , shakeel.butt@linux.dev, Michal Hocko , Tejun Heo , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: dtm85wkrb5to8ox3iiukfpfafb4af73p X-Rspamd-Queue-Id: C0EF5100008 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1731792781-560520 X-HE-Meta: U2FsdGVkX18tg1u6uJor3F+BVczWWpQpFPawy2XXiN1E9oMFfdURlCok1AI1ghEFsLCKrNhoDNI3+CmwJHxvzhsMW9GrGhCerjtU8fVMtq2iOSMCDppzn5y9QtouPUSfNT2MiPKfj1IBFYseiEi7tJuoC4ajf+0XZhdt6yce65M5yZRWpXIJANWFewxCUfKsycBxQp9HVRBd05E6JGjHKHDIo4ruNi0vYi/S95tjMM/gO2HZxNWjn8gWD9QBkvL+xuk5p3L+aq0/wDzllrJGuf1LNIKqSVVxdbZPo9QhqjGMCqhPiYclLxruqpxUEPl/jQ4IqULRh3DNlm2TVVUUh/FxVpoZ+Ga3fVYb6/QABU/YED7gR9zBtYbKPGMYM3/IQjkRSXqdXdbBUwyMH+uxIKqIfANDpoLK9Obs3rEDAAxnXMMHikegFLRNuAdgBQjdOFIl9H7kNfCVnbC2b5WEHyO4MpgUsLV5XdigYkiTrxYzhDzR9sNw5TMYd5TbG6aLoDIPDr3uxCMOQvGLs4gTnldeCWQXTf+z0+4UenewLJeGj+xvMPWOtcAq0XnGiBhjtqaVP4eFMA5Pfi/PyH7YtOyU2YIF3YED3QKKRijNlIgvBiReNhDmWAp5N5IIE1gkQM8ezYVRgXcZIFcWfD39zSPPlmWv/nDwpcx0apxwqY85n4UMl/KhrlWJp7m+uxXcx4cPMPLDch5B4OxgHAD+du8vLRv/RaZwjRYcZbyWUtNaWvmi2fpKvuz3jywpoZrXl4SOP8utU0/m9sTaK81WH/AKBVd75LXYu7bXri6gi0rS/u3xg0Nv9eYQ869lpieCkQd/Ws32XXxAx9ULaG0NfzEBVZWBskPlBkeHQXAJcxmCxPJdP1dg0I2XVATgRYWHiGjTplbtQnSBl3c3U2BqpZtduFkGDXC7OYsMFTYZKr5mAU1UJKJ6wPt9EznTF7IFOw+2yf9nK+/PGpvWKZu /2knD4i0 Uynu8kH11aGMllduj0D/fGBthjdySbE5xcEY/aIXYOwiocv1e+QgwNcvxOMLDrx0/IZMDyIR/MH4iDTxaDd1VJYAomBLlD2Z04Vb4CwVBOiKNE8kVYtGqNdiLbCnhZ8I4+b4Awak8ijMWSVyk37OdlYFNJEGc6UCNWq1VccvvQaK3cC1dKa72kPVjOdnLoU6uVb7zb0B+wQb8VqmIsUw+XoXjqInJsnTTwcfMHHkqty/0XQzoo9VExIwN0gdvLFKlYctqAreRjR15X3Qj3WB7Sz5oGd53D66d45LPWaSlkbypEykRTIjAUK1NwcrD2mj/xtcseI5MnfPkG+vx2oF1AX6/jFFJt5LLGQFt8BFZ954O57uNCme9DdeFWzpyP8jyvjasLmIPufQfYn4/oJ7XTUTJFLP/ys1dtNwc0Pw+UyAABp6dyonA+54oHsphMimPQajBRY9LK2kYc8rXVzQ8oheGLGfmHbjidCR9 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 Sat, Nov 16, 2024 at 1:13=E2=80=AFPM Alexei Starovoitov wrote: > > On Sat, Nov 16, 2024 at 11:42=E2=80=AFAM Peter Zijlstra wrote: > > > > On Fri, Nov 15, 2024 at 05:48:53PM -0800, Alexei Starovoitov wrote: > > > +static inline struct page *try_alloc_page_noprof(int nid) > > > +{ > > > + /* If spin_locks are not held and interrupts are enabled, use n= ormal path. */ > > > + if (preemptible()) > > > + return alloc_pages_node_noprof(nid, GFP_NOWAIT | __GFP_= ZERO, 0); > > > > This isn't right for PREEMPT_RT, spinlock_t will be preemptible, but yo= u > > very much do not want regular allocation calls while inside the > > allocator itself for example. > > I'm aware that spinlocks are preemptible in RT. > Here is my understanding of why the above is correct... > - preemptible() means that IRQs are not disabled and preempt_count =3D=3D= 0. > > - All page alloc operations are protected either by > pcp_spin_trylock() or by spin_lock_irqsave(&zone->lock, flags) > or both together. > > - In non-RT spin_lock_irqsave disables IRQs, so preemptible() > check guarantees that we're not holding zone->lock. > The page alloc logic can hold pcp lock when try_alloc_page() is called, > but it's always using pcp_trylock, so it's still ok to call it > with GFP_NOWAIT. pcp trylock will fail and zone->lock will proceed > to acquire zone->lock. > > - In RT spin_lock_irqsave doesn't disable IRQs despite its name. > It calls rt_spin_lock() which calls rcu_read_lock() > which increments preempt_count. The maze of ifdef-s beat me :( It doesn't increment in PREEMPT_RCU. Need an additional check then. hmm.