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 80ECDC28B28 for ; Wed, 12 Mar 2025 19:06:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F382A280002; Wed, 12 Mar 2025 15:06:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC213280001; Wed, 12 Mar 2025 15:06:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8971280002; Wed, 12 Mar 2025 15:06:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BA795280001 for ; Wed, 12 Mar 2025 15:06:25 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B563512156A for ; Wed, 12 Mar 2025 19:06:26 +0000 (UTC) X-FDA: 83213829972.19.E146C1C Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) by imf05.hostedemail.com (Postfix) with ESMTP id 5593D100019 for ; Wed, 12 Mar 2025 19:06:21 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=pQPjkoF1; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741806381; a=rsa-sha256; cv=none; b=2AOiiAUN26iAq/jEPWdhSOgh+fHSgEMh3Q8HCFJIryVUsNgcdsPDJI44iDcIjADrvZwts1 lfa18+RQGmB9vmPvkouRD2DLNzBcdxxqx2pS3qRbcPRlHXutJI/Vzi4fNcZytEEUpEW4yL iEEMDAkNtIjDe9jsRLAr82OWG2GlJUc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=pQPjkoF1; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741806381; 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=taQrTtRT6oKrmvrbMflaeFBHHQcfBZ3zC2RW9QpVfrE=; b=F8cuHGVQnEeFlq7pPQJY/DuLKEMJAomwcjTEUJatg5AVm2f5Tpvjf4IxG9pyXH89HBGZpw 0I7JIrwvLpHj9mUZXKDknTlHPRZ/2QCBIxZOOomKgWxH2O81M4xdUw01KCqBq+TQUc9lk4 jK3TxFkNc0nzINKJGvVa/cCzR0a0W+c= Date: Wed, 12 Mar 2025 12:06:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741806378; 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: in-reply-to:in-reply-to:references:references; bh=taQrTtRT6oKrmvrbMflaeFBHHQcfBZ3zC2RW9QpVfrE=; b=pQPjkoF1TjMWNogAMZSj/7G+VJWY+f94bgcxZSrwbLOtQtg3hQZcwKl5UAiLFO0zbNCUW+ 8nEMMjtbDq/oCiOxHHvCbeYjDq6nBHgmKEcdtOtoqZ5oNkkCyxPnT4xjjNTffHlx/HoIkh j8I4Aq8oUWThc29uOsDlcC+VX/VVlpo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Vlastimil Babka Cc: Alexei Starovoitov , Andrew Morton , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Peter Zijlstra , Sebastian Sewior , Steven Rostedt , Hou Tao , Johannes Weiner , Michal Hocko , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d75c5a8-a538-4d7d-aaf4-8ecf1d1be6b9@suse.cz> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 5593D100019 X-Stat-Signature: 5swpzc7u8xdxrg7eott4wd1b93587ktc X-Rspamd-Server: rspam06 X-HE-Tag: 1741806380-76883 X-HE-Meta: U2FsdGVkX1/oyvCZcmL7J0hIXW/7JchuQFGXM+cWRHhIa+XCV6RLB0Cglj8qfYNvbYS6dUK9OI1dbpiU2ktFPGryKxiHwtd5JhKBbDTwZlFAb1NMvs72wWBuHcptDcjIg1FK3+LbkhZtpmOfYo0k20eCDyq6TgVTeXSYPUwE7Tteu4pXdc9vuRdhZJbMjxWiqnMPBlGWF2e5mZN9fAE23BqIK3VlIV0Xi4t6zYJxdhHV4xFACWCTaVbZomuOD7Q1Y6h/Dosrtzfk7b4+s0kgrinmUzikpDFctVbGLasAZcMjbQFkkezYcQ3SHi+Cj+q8JAUzvpwcUSSVrENPoDqofRyvLW+y6ZmP8J9ZUcJ/qIN4pR+Bzxl6hi0dV/MVygbmmzW2yIuiT2VbcWZh6/4c4lxpGpw+4kgPJGbi6cjSmTgLSZUl+s69KyQl8K4mbD0fxVlEXJj8xkgceOqQfIBqPNk9NtypyFUVwhdvSsx3F2EnfDOuT3NKA8UBLDDwUd1FuOQhTSpEWmVCpSi/7JAKygMVkKwOG1INHH4ZoN70FAbi55HuKriUN2Emql+jE7HlVl2feDWjU2vudilwftDeWDbDs5uTszApTITNNf34rkoza7eC3mZBZTuY2qmVvg/DkU/Guygz+F7ScwXV5mol0mIcbLtG+yhgjD9ypgjpj41ehARO6l2eRXDFkbAmodQNhZT4beVcbIw89u0IVVe8RMh+0Ho6XTUfsMUzxNIvacCoVxSTbZsCmxp8L0wtI4AC15RamErIpzal70Fb0Yc++O4NIyIrq0z0tYIg1fqhHybqvcfo5ePkNeYonCR9GY7e/ftUfaDdAGM/kzuAGhVPcdutAdyYYSNFu2W/QWThPZkn8fMieQEGnruvUAWqn7XOCt8s/S9Uj565GhCJqzJwMpa+j/wuWwBC0WowPHnRckxb13GOEDRfDKlkYyV+8ImQLP2SKmk7gO5em2zqoG6 UkFsMhR6 BvYHB5hHNuu0enay05XsW1mPUgZUfU95jsUK4uELr7QXpBVeXXAgIOYYid3iSpxzZu5owA5jjDc6XnVQq/t8PB3qV7ixHi+OaEo7a6dtDLt6Wc/U/5MywcCfxvYL8ycLa5ETccdZwwm8kZ7FdMtPCX9UdiB2QpdMlDHC6LQaMtcD33XgRxi1IDN58t4WLN61lPUrGfADniTU86diDgJbsLO/kE8flxrwtiv1BovhCwniSMe2Nk2BoE1YIRq2pi9e+5n5iCVceIPGM5g66Ai1pVmlGU6pLeHQJRjmT/Eq38i6FtK4= 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 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 am on the path to bypass per-cpu memcg stocks for RT kernels. The stats would still need to be careful but I don't see any reason to keep the complexity in memcg stocks for RT. IMO RT should prefer predictability over performance, so bypassing memcg stocks should be fine.