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 8EB00C3ABC0 for ; Wed, 7 May 2025 11:13:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3AAC6B0085; Wed, 7 May 2025 07:13:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE72A6B0088; Wed, 7 May 2025 07:13:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BAD936B0089; Wed, 7 May 2025 07:13:53 -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 9C0EA6B0085 for ; Wed, 7 May 2025 07:13:53 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6594DB5A9F for ; Wed, 7 May 2025 11:13:54 +0000 (UTC) X-FDA: 83415851988.08.641DFF8 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by imf05.hostedemail.com (Postfix) with ESMTP id 9A7DA10000B for ; Wed, 7 May 2025 11:13:51 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=A7tlvnLE; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf05.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.13) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746616432; 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=DsZSWjqsiFPpZ5Q0IfvnBJtEENDgdRSPccZ4YXdST6Q=; b=ovAoVshC4GMqyad0nG9+qzdv6FWye83WhoUZeb4XsH8kvXdb/hZzrHKnJleEAuFNkLG8XC vqWBxaZftlXdZ7JCmBwJZKWPVNRPOVCQ4f64O5bb2rizZWtX88n6GM/v1gRQ8mLzUGn83e dhYPc6k8oTS0HLRE09OC1e/DhZ+kvBA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746616432; a=rsa-sha256; cv=none; b=IZbKscvnj0Sukj1OBBARPpNHjAsCIRBKI3YoZ2sdxMmwk+/rpa9gkO1knA+XQZXsjLhZqL o62kPk8BhkpGtctwiHr6sO3whn0HHnNDKyjs7dOYLWXS8fORxHbMAyIRxja7E/hfiaHX4x ic65aAUx6lPhd1PSKt6RIazJJDPl+LA= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=A7tlvnLE; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf05.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.13) smtp.mailfrom=kirill.shutemov@linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1746616431; x=1778152431; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=mAhoWh9DxEqhUnSdwA7h9a1g8P8EZV5LJP6A+LYFtdg=; b=A7tlvnLEpM75l8LiIeLea1cEs1vworfiLa6xeVfwO6X3enNvK2eQY40V 3B2m8JEUghHifx66aRJ3xIKANYbtR+BWpmCNGyaZ+w54gwhV1L1VHNLgh UveOTl2dDBScpVAMCOc9yBWjwXZSe93igNK3UGTfcq2o3Zjtzu2We//WG cMoq+I+eEbX3IXiM+UIX2+3FyHrtD9qElDOp56rIrSb6D4yP1m76dvzc4 RWMT+Melw6HgAsNwzT4d6e5yjphk9pMHmfWrqpxpsoi5OA5h0y4bhP5cc yq0JP1Ncz4LWLs2u9IHhBYUaoJASM7a7+ipvx8cIZyhrPd94ERizj8DkH A==; X-CSE-ConnectionGUID: vQP7rrNWTj2w6DGIyeMuQw== X-CSE-MsgGUID: ocCpsW2HSYe25bbT6lAoQA== X-IronPort-AV: E=McAfee;i="6700,10204,11425"; a="59327271" X-IronPort-AV: E=Sophos;i="6.15,269,1739865600"; d="scan'208";a="59327271" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2025 04:13:50 -0700 X-CSE-ConnectionGUID: EIKxZXoYRF+PJn0ZmBS7Ow== X-CSE-MsgGUID: C8/6LO3CQlaRAsVn9KMlMQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,269,1739865600"; d="scan'208";a="135636497" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa009.jf.intel.com with ESMTP; 07 May 2025 04:13:47 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 7D64719D; Wed, 07 May 2025 14:13:45 +0300 (EEST) Date: Wed, 7 May 2025 14:13:45 +0300 From: "Kirill A. Shutemov" To: Alexei Starovoitov Cc: Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Borislav Petkov , Thomas Gleixner , David Hildenbrand , Alexei Starovoitov , linux-mm , linux-coco@lists.linux.dev, LKML Subject: Re: [PATCH 1/2] mm/page_alloc: Ensure try_alloc_pages() plays well with unaccepted memory Message-ID: References: <20250506112509.905147-1-kirill.shutemov@linux.intel.com> <20250506112509.905147-2-kirill.shutemov@linux.intel.com> <5loiv7lfplpruujplz7wmzj25g34rs2aezvrfsl55dsddrh7mo@rnqrlx5zccol> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 9A7DA10000B X-Rspam-User: X-Stat-Signature: ttemqohkzhk34pc8t1sqzo9u1w96x1jz X-HE-Tag: 1746616431-397422 X-HE-Meta: U2FsdGVkX18CPPEfiT/wq6banwiXJF93UCzPyvi22elyldaBfK+2kDhXbsgYOEbCAwoix5TeZKss1BOsOW2evO90Q7FGIUR0X3DQmffGGRD9Q+qWA+0fJ5QJppeTFyXVAjbTKcsmGqoSlBBV9Mp5ZYaEu9I0rt5IYy4UfqvuK5Ql/Y0lK+Oa/blPcD4Fn5KzFWhvzJATK9BW3TjCz8ZRdLccKPFhUpaO01Ymca1cX57jFfU+mbpK42gLl7wtahupcFpnuxBRMCJIKjMn2d5KKJj0rJse0HrZYtwAPdJKtu7rgIHJG4TWEq9WM0K717bdJ1gd/POu5UGejX04vv78MUYvnhJuuWYHEOzM6KZi1xBV+F16wVd4mAOnT4lTPoV5AHFRDcsguOclDHwcviClp8vM4qB5uyhxWwRzcktc8gwdaqEHR1qN3Wvr3X251UZP60db+wEYXEJW3GFvRqOWiizFcCoZJy3L3UvD4vkpMtuKlwmvPz15ovrdYolL4MvWjhoatRex4Htame1jkio0EnmMAxKsQ0Ab19RBUv9YikhQDh8wD+pOqfzeGbsVBzn3kdf7T0YJfBx7msiJrUFa3R6khZkNHpgpQcM8BkZtAbwi1qzq6CvJhLRAw7rw9DknfaVzGsaRW0tRvLypp/NfnLGfRyn7lIe5HmExut0aP2bAYPmzfyFWeXC970MNz3jt0kCknelCIFGd7wKKrjdHpT1xaNqRvozjLZU95ZRgYhFdXBZXiA0xgE37r20/Y1cXh92nWk2sHefotmF4Yf+G0PFNNS3ruzhgWjbSwiGNM24zYIT46l+QvSoBOuJbgQKPJ95PZrVZRBCV4Z67dKyOBhEHE8c87u+txlnFS7kP3umJJUMlyHbPPXfJxzZfe4FaC9sJGu8hKSRvVa3m2dlx6wqCvlvRsrcpbiqSjkFhJaDry3UQS2U/T3GztdIpf/+qjRs9H83Xv2K/u/GK/20 c1a5KtLb 7RSZm2kQ5I2cCj64AX9MPBS2ZznT+Q5Li0Pketk8uzf281iw468DLwuEk4HU0zUzz54zJawblgLfQ88TaYR8wvRkr+1046HVU17teLE1X6NalSGepKR2rPyAFKpgodRq0ptCxeYzLqzKUAFNwzN8btY3O/AhoOCyUNZVhCRCFIjx88vXHKh9GT0yJTWy2OpgvHpS/Gfs/CPeLGDV5cwxtPqvIV/EQBnrNxivNjkYw+3jjpEH7HXc7SXH7gerWW77hvMySWI3eTfgrZo4Ym8rqgcyK0OBXG6TEfV47FIoVkjxsPiFPVFpGaDlopIOP+ngGLF5N0nHBwis2EqyPAayLaD2iYceFna0wCU6HDeviIkzTZm1f203qZmKYO2fR1zfFjwbu 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 Tue, May 06, 2025 at 03:05:31PM -0700, Alexei Starovoitov wrote: > On Tue, May 6, 2025 at 12:00 PM Kirill A. Shutemov > wrote: > > > > On Tue, May 06, 2025 at 10:18:21AM -0700, Alexei Starovoitov wrote: > > > On Tue, May 6, 2025 at 4:25 AM Kirill A. Shutemov > > > wrote: > > > > > > > > try_alloc_pages() will not attempt to allocate memory if the system has > > > > *any* unaccepted memory. Memory is accepted as needed and can remain in > > > > the system indefinitely, causing the interface to always fail. > > > > > > > > Rather than immediately giving up, attempt to use already accepted > > > > memory on free lists. > > > > > > > > Pass 'alloc_flags' to cond_accept_memory() and do not accept new memory > > > > for ALLOC_TRYLOCK requests. > > > > > > > > Signed-off-by: Kirill A. Shutemov > > > > Fixes: 97769a53f117 ("mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation") > > > > > > Thanks for working on this, but the fixes tag is overkill. > > > This limitation is not causing any issues in our setups. > > > > Have you had chance to test it on any platform with unaccepted memory? > > So far it is only Intel TDX and AMD SEV guests. > > We don't use them, and my understanding is that such > unaccepted memory will be there only during boot time. That's false. Unaccepted memory can be there indefinitely after boot. It only gets accepted on demand. -- Kiryl Shutsemau / Kirill A. Shutemov