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 CD0C8C282EC for ; Fri, 14 Mar 2025 10:16:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AB48280005; Fri, 14 Mar 2025 06:16:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 95AB3280002; Fri, 14 Mar 2025 06:16:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FB95280005; Fri, 14 Mar 2025 06:16:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6084C280002 for ; Fri, 14 Mar 2025 06:16:30 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D4B06160E65 for ; Fri, 14 Mar 2025 10:16:31 +0000 (UTC) X-FDA: 83219752182.07.88400F3 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf16.hostedemail.com (Postfix) with ESMTP id D145E18000E for ; Fri, 14 Mar 2025 10:16:29 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=M6CwWMS+; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741947390; a=rsa-sha256; cv=none; b=af2Dw4GdMqWWwSsiIp9GltyZNpGx1uHWvrV0WjcQGZgb9XaP/z7QuTQX3ijL3aaBWPQTDg d2psGc2mjzWt5Z0y5e7WWgvmaCT2j+16hlffFaimrkaUP0LhbJVieZGiB1IWcC/rBhV0bu TSPzSZiiRIQAR/9I2EPCKUMGja3FN/g= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=M6CwWMS+; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741947390; 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=UlooZCqpuuYmk/BU1NwLBULyb/9UA2hcKvt6wavKqTk=; b=g4AxlTj5RDAGFSOBx4D2ojgRDw28WsXSr3pnILRlfS2Ii2AQy0ay9lGMUy6x8McV0/AUtx jaUHcnDgAGhH6+x/XwRjQozvT2oLKJNVlaB6Z9eXKJ03fvtnPQDweKlU5hvFvDjM95eCfr nV/Tgb2w052tok4NTMPNiFBAjdMNTWs= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-ac339f53df9so41260966b.1 for ; Fri, 14 Mar 2025 03:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1741947388; x=1742552188; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=UlooZCqpuuYmk/BU1NwLBULyb/9UA2hcKvt6wavKqTk=; b=M6CwWMS+E+E94PjF4UwHmCIzbZzO7om0NzrGvPYok5b9si8kyeztzxLXG363TM4Fwi djRpO8orclq2GrKomO3LfGwpuV6GlAsX8zRmZe/vTIPK9DuAG2pW8TEJVrzv5USUbO4B UhYmQKcvb/hgq4vwXo/ICkzkgPo/GRTmspgdYfR5Ourwcu/JK+/3OEWaCE7La2mRBSCU jaHmE3R45yNvj0SpydfnZdCK5DPJyUsKP/01oXQPY/m2VoWUzCNzonzDghwgwj8vkwae MWZalqKZOK1CG0bE37VSwRunSlxy7NAFb5/Me8PFFp0fI8CsqWU+KGH7RRgoeXS9REQ+ qLng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741947388; x=1742552188; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UlooZCqpuuYmk/BU1NwLBULyb/9UA2hcKvt6wavKqTk=; b=UU4K19DmGIdKPyizP7+IB2bCCNShZfvKABSoli3cBN/5ffhMSDfUttPbdAaVxS2GPG 7Iev4Y24fRp3xO1bJCgtX14B5osa0i3w1PWr/LyYDGxejyT736d0JZzM2/Ipy7CvRC81 6YglZi7wl3JMTh3Qk/DA4esMz4DtQXJJAImLFpAWmJWQHhgHG6IF3R8RMDwztn2B3GhG 3U3Fus/HrsL0NTnXR7wJ6tbc3V0WLN1KEw8663QGHYxmAF3lXHNQgblPCHuFp3+zlJ51 gLKBgsJrpbCcrEfIe6F+F8rquWe1rkQ4NQIbmU6T/RyvjWwFwlg6JzufX0tyOQCm7UoW V+Gw== X-Forwarded-Encrypted: i=1; AJvYcCWdOVOpn7HQqd67Aclkw3RNCu3akpRG+AShqemT9D8H0qn7AxhKd5aZgyrTtPTNIGvB0NcCc6BxxQ==@kvack.org X-Gm-Message-State: AOJu0YzmBugEvNoVx5phiMJ2aOEZqLM39yDl9T5YuRXFnulGGr1EJOpd ghc3nmxyfPZR9WekJS81bJz3Y5IMOixcKj/TIRnUAUF7mS0VMB1P8MzIBvG7+/Y= X-Gm-Gg: ASbGncuZo3JpnIlqZNvix+eT0b37BIa1XpfP+t2/tgqcTMhWRw4sLEg44C4YRRFLwT7 XRe8AEE8SZTVUUsxQNf0ZO4m1vLZ4M+C00bB/8Il5VlSbcZSqB5rbjwlCSDI6XgdI9eGmabKpeA 3XjBA3z3yDWJnteE3cKXYz61TgA1prDGWcq2ZQ7KT93dLGrtlZCxr0HBBDFJxx0WlO/udTiLNF4 lBs4JssE5yl28t24NnVmrcdkHcprKR61c1KAwZd/uAkWEplyExgBSWBm7i1P8+0flDoDSEsFs0C 3f0mDChZT3znngVLhs+3PyPb4WwjefYceRL68u9wAh9yydrHAm+yGHylFQ== X-Google-Smtp-Source: AGHT+IFIRZIpZU1ud7THKhfimdrL/Ki5fS5WMHUSVLs0E4NFQaMnaEfc5B/VLMfbRmQ0qXg0VbNxXA== X-Received: by 2002:a17:907:2d0f:b0:ac1:de84:deba with SMTP id a640c23a62f3a-ac33017bbc4mr211515266b.19.1741947383260; Fri, 14 Mar 2025 03:16:23 -0700 (PDT) Received: from localhost (109-81-85-167.rct.o2.cz. [109.81.85.167]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-ac314aa5166sm207946466b.176.2025.03.14.03.16.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Mar 2025 03:16:23 -0700 (PDT) Date: Fri, 14 Mar 2025 11:16:22 +0100 From: Michal Hocko To: Vlastimil Babka Cc: Shakeel Butt , Alexei Starovoitov , Andrew Morton , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Peter Zijlstra , Sebastian Sewior , Steven Rostedt , Hou Tao , Johannes Weiner , Matthew Wilcox , Thomas Gleixner , Jann Horn , Tejun Heo , linux-mm , Kernel Team Subject: Re: [PATCH bpf-next v9 2/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation Message-ID: References: <20250222024427.30294-1-alexei.starovoitov@gmail.com> <20250222024427.30294-3-alexei.starovoitov@gmail.com> <20250310190427.32ce3ba9adb3771198fe2a5c@linux-foundation.org> <4d75c5a8-a538-4d7d-aaf4-8ecf1d1be6b9@suse.cz> <4a52db5b-f5fe-4a60-ba17-a634a2d0b7af@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a52db5b-f5fe-4a60-ba17-a634a2d0b7af@suse.cz> X-Rspam-User: X-Rspamd-Queue-Id: D145E18000E X-Stat-Signature: uic1cbkaiyqa4fd78t6ynpni3utar8qn X-Rspamd-Server: rspam06 X-HE-Tag: 1741947389-641297 X-HE-Meta: U2FsdGVkX18ho1EkzlSiqU/fjtI6mlU0lzhyqaSUj8WR5AV7ozl/zbDPdJ4eVkdBPEn0qTFewZ5T84ye5qza8U0rYDS1KQ+sufJa4Qt0Fn7p8DNsroinfnpFPjSnFalPVk6tOuYCxO2EafokC95wK/qoGVo8tEmTBHQgpxRDXICRgbCvFplbBrzRZTowUgw3lRMw9/jr/x6uH/63SaT32XPtYqCyYg7+UbB9nzmvvsgq0m/SveE0ZVDRD9qEsnb4UcQqpmc3d9gjL0S1GEpU6/0ViCrT/QzVswsDe31bU8NMC4T8SipeV4oDm1LrxmBHQGZNP/QJhZlfrdBVZ5m7FGWUXXWkMFzpLip/jPH3MlCVdqfKrgwwZ3iuw2ZnXpR8H4XqJuzIdamVp3d8YGWEQuUty/rAIfjzlLyGlNIzmvmucj+OlaR3ovupW2WPC/6ODSIeDexf2Mh6qFA6UN5okw/2A4ZNR4ZxHbKCQJyr7Rm7yd8hUmIjQDOeSJqG8NCATnFN4uJBRpwpAcj3KCqdlsjc6oqHU2uxUBd0x1vf3T0h8aDfTJ/QRkNSAd/YchmQX0xMxBNKhH/rW/WDLckjub5/omkLxihN4GjrdyefyjfSSszCJk3X1jN9DAmWgQSBwv/HGgrZGQO+eVwsV5O9t1xKO0QT2Y3thkEA3bUbte4j+IL9CEfZUn7FjaXzrkKWzVPHs0Uu3yv+2kb30lMb7tMAtRcNMTdigQH8n2GfjSbJtEw7vDBvkqOjfYAEeAql82rBGvlApKcnrnJJQfXkgILZ1k3kup+h95lpPR0hFFuVu37IylJyXwQf/LBWAGJCblf6OldSlnHI1nO53Zb6/LZe/+lx+nxJ8dIygDlJS+A3EA5+JteBaxXCTtK8ksrWM6CTorCf6H2pknqkimaAqUbvxKatJwJLBlm7KqVtoHxArraBvoadbHYkIcrjwUpqdiAIQdwhAtp5dBOaMqV pNMeJR+B 3zW5owl550AJ7tqXsGKp36iXzRRrtfqjqyf/ZWdqrQTs/P6adRNUaW1cpw+BX0082FLE+K1h9j1NVGdJHNryRCwheAneQXloFGz7p6ci8rRJKYOunUzq+XowyHAMBXQkVuOYttkgSdT0M27hEztcnIgCjuSQ8KkOZ7Svu/Qr5SNB81aAnH2JvZVIYiUJAsT4EXCPSwSXzN9vhbPMDMLRiM3WwpxZy0AYELVFGrscEPwRGv8yed3BGJi8s/kWHfAAe2IwT6XWpDxP+BzNLmmxbrp+Yoi2a5IEfOnSh0MB8H/ytyrdpEBmc/7Ti/4ZBwWLXYPvFd2TwGY1eKrtHUVAr27/KdHmC0o6TscPKjNK3hOF3+hFAFg3mnSz9DQc9snShzrqB1WmG/GscH8RVzSGVvThG9Mmvf9kLx4yk889ofaaAdCeTVlhdgSHjig== 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 Thu 13-03-25 15:21:48, Vlastimil Babka wrote: > On 3/13/25 09:44, Michal Hocko wrote: > > On Wed 12-03-25 12:06:10, Shakeel Butt wrote: > >> On Wed, Mar 12, 2025 at 11:00:20AM +0100, Vlastimil Babka wrote: > >> [...] > >> > > >> > But if we can achieve the same without such reserved objects, I think it's > >> > even better. Performance and maintainability doesn't need to necessarily > >> > suffer. Maybe it can even improve in the process. E.g. if we build upon > >> > patches 1+4 and swith memcg stock locking to the non-irqsave variant, we > >> > should avoid some overhead there (something similar was tried there in the > >> > past but reverted when making it RT compatible). > >> > >> In hindsight that revert was the bad decision. We accepted so much > >> complexity in memcg code for RT without questioning about a real world > >> use-case. Are there really RT users who want memcg or are using memcg? I > >> can not think of some RT user fine with memcg limits enforcement > >> (reclaim and throttling). > > > > I do not think that there is any reasonable RT workload that would use > > memcg limits or other memcg features. On the other hand it is not > > unusual to have RT and non-RT workloads mixed on the same machine. They > > usually use some sort of CPU isolation to prevent from CPU contention > > but that doesn't help much if there are other resources they need to > > contend for (like shared locks). > > > >> I am on the path to bypass per-cpu memcg stocks for RT kernels. > > > > That would cause regressions for non-RT tasks running on PREEMPT_RT > > kernels, right? > > For the context, this is about commit 559271146efc ("mm/memcg: optimize user > context object stock access") > > reverted in fead2b869764 ("mm/memcg: revert ("mm/memcg: optimize user > context object stock access")") > > I think at this point we don't have to recreate the full approach of the > first commit and introduce separate in_task() and in-interrupt stocks again. > > The localtry_lock itself should make it possible to avoid the > irqsave/restore overhead (which was the main performance benefit of > 559271146efc [1]) and only end up bypassing the stock when an allocation > from irq context actually interrupts an allocation from task context - which > would be very rare. And it should be already RT compatible. Let me see how > hard it would be on top of patch 4/6 "memcg: Use trylock to access memcg > stock_lock" to switch to the variant without _irqsave... makes sense. > [1] the revert cites benchmarks that irqsave/restore can be actually cheaper > than preempt disable/enable, but I believe those were flawed -- Michal Hocko SUSE Labs