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 9C0DEE77187 for ; Wed, 18 Dec 2024 11:32:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8DEF26B0082; Wed, 18 Dec 2024 06:32:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 88F236B0083; Wed, 18 Dec 2024 06:32:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7567A6B0085; Wed, 18 Dec 2024 06:32:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 57D726B0082 for ; Wed, 18 Dec 2024 06:32:26 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B70B2120CF7 for ; Wed, 18 Dec 2024 11:32:25 +0000 (UTC) X-FDA: 82907865432.25.7DAE99F Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf19.hostedemail.com (Postfix) with ESMTP id 7BDFF1A0014 for ; Wed, 18 Dec 2024 11:31:50 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=LvgHL1sb; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734521529; 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=fnQWqaCjqBtW62hSVEa2zhH4lywtPn54oTc9oEo9iq8=; b=kDSdSd1f6p0iNonvo+8cEzuXkgYkehz4OONC9XN3Xv3+GGkLEG+fFQ+oRcIfHAJP9sjL2q OEX2suyhIW45Vq1J0JyY20Af4GbJO1CXiAMf7HSV3mYnCqb/DN4yqapEjj78tMkLtYwiQU ETuZO5dBTWpmCd6iyCkWDwFcd2/9qIg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=LvgHL1sb; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734521529; a=rsa-sha256; cv=none; b=spDsoJZrQXYkdIhuHM3LtjqZcKA9K908R1BVRi1e75VondZ6ffEMI/N1yQQmqm9Kqj9p3x 1w3nVwffEvSO9coMgHM5hveKs8Z/q7/sXyqEvd3fY6cr/G509HnkRd8kecE/wpcdo7Uny1 UvXdSoRuyCSZ7lsXYrIn+XYXGL7AUl4= Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-aabfb33aff8so64726966b.0 for ; Wed, 18 Dec 2024 03:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1734521542; x=1735126342; 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=fnQWqaCjqBtW62hSVEa2zhH4lywtPn54oTc9oEo9iq8=; b=LvgHL1sbmZqhaTgLDeaT7WoKU0gdZIRK+p6tgdSSlfZ1RknJS/w7N9S3GcYW2Nkxki lBlczCWIIY2B8lHZ32/lBrPIOwbUTm9WjX2/LsJ9YmbcJhjCKywo5H8YQb1r01xyvd4C YMiPb+qPHFBYfeEVIMNRgVDgpDO4LP/sHlKbuoydN3z35317ruV5DDRBNX5TBXKu1D6H 3CHvtQjBXGgw7KTdcNNFhotAvuM76G3wxco0U55t4lOwjYK5VUlM7fFtpjRgwcQ5hIlI R/tIvu3SqYaC8okChfoaNDwTbYQdjLxRC4cpWLQK3b89TOY1btWJfac+RDyDx/TqdGxa F2BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734521542; x=1735126342; 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=fnQWqaCjqBtW62hSVEa2zhH4lywtPn54oTc9oEo9iq8=; b=Wan0MtnlbBD1RRLonxo+d3/b4mVtlHJj5bl+IP2OhGuOvBuO+fEZyq6uP7ThquU+J2 ySU8HZ+C2FupOO8xpW243/cwEmDuNndbwpNKMXxOQPop8H5Mv24tpkZOBIAzGdg5QRuw YD+bV8g8Y8QdY3WbDtuXhKBIqzTttyyyXqLCIFBq5uP3NDQFyHAbgztFLZN3Pe3VobLG cL3jKA8D3W99d7dOeb08Y76qEdzuo2e5+ZhRID92ndBkiBak8sNA6Djoi7sM3r8mMYjT ayHpbBJIkamf7u3U+97aE7sTg51r7b0cU9qwAW4ejMstOZlC65HwSPmIASeAN1v/gioS xagw== X-Forwarded-Encrypted: i=1; AJvYcCXPmfORUxi2XjE7WW93V2eeNR+zjiGccUIEMgzsPquZQU/4tdAISLEeZfUZydOguDbmlALUXlfRBA==@kvack.org X-Gm-Message-State: AOJu0YwNDnMEwkOKBFWaqzL+vjAxMbz9F6Enlyo2WZvKeO3kAnrNPtGJ sldxfdxJcDUV44VnchskiFLKXpGMrg2hfDJnV15g+wL8MFn0aNS8ElcHGrxtRek= X-Gm-Gg: ASbGncvRN/sp/Ye3FM/Z9vczxHjtoqx8N+1Kfo5S56L88zecYnZJsqdNiWu+42iTFfe yX5SooZ87g1Oc13Cbsam40eq+hE0fmWgZuNmtzA9XjGZ+40g4IJn5NgmMIeDZ9vrubrsmAHJhJb 87r4/SFTfp2LC2g1QWwFuxtQo5omANWPhPwQ0xutwyjypohGExf0AJW+uMyxFj1w3rbZfXgwcLJ BjYxFg63NRM1pdRGMP9iYSrTCzmWXvNugM6gEv4BD/4M51Ezi5SYwA1XLE2oZVlokM= X-Google-Smtp-Source: AGHT+IEq9wnIESLmBVjyloaj2K7ZGM8pEepkcYNy7DpY/9QMzrt5l4lU7LiVeEPEXPuazvcO/CaAmA== X-Received: by 2002:a17:906:ef0e:b0:aa6:bedc:2e4c with SMTP id a640c23a62f3a-aabdc833a77mr769119766b.3.1734521542051; Wed, 18 Dec 2024 03:32:22 -0800 (PST) Received: from localhost (109-81-89-64.rct.o2.cz. [109.81.89.64]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aab9600628asm554534566b.20.2024.12.18.03.32.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Dec 2024 03:32:21 -0800 (PST) Date: Wed, 18 Dec 2024 12:32:20 +0100 From: Michal Hocko To: alexei.starovoitov@gmail.com Cc: bpf@vger.kernel.org, andrii@kernel.org, memxor@gmail.com, akpm@linux-foundation.org, peterz@infradead.org, vbabka@suse.cz, bigeasy@linutronix.de, rostedt@goodmis.org, houtao1@huawei.com, hannes@cmpxchg.org, shakeel.butt@linux.dev, willy@infradead.org, tglx@linutronix.de, jannh@google.com, tj@kernel.org, linux-mm@kvack.org, kernel-team@fb.com Subject: Re: [PATCH bpf-next v3 1/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation Message-ID: References: <20241218030720.1602449-1-alexei.starovoitov@gmail.com> <20241218030720.1602449-2-alexei.starovoitov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241218030720.1602449-2-alexei.starovoitov@gmail.com> X-Rspamd-Queue-Id: 7BDFF1A0014 X-Stat-Signature: zoonezs4fe13wfaffat7fdwoiww1h8ny X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1734521510-947777 X-HE-Meta: U2FsdGVkX19ipq7n4fGwibS1JQsh+Ft1YD16BJGmM63Z0JevS+hAw9Zynj8RC6A48CMLyoswwMZBH5hUbqb/TZ6vk4fdL0dl68knmksIwKT4rd1wJudZPRsWOtrimGy51je2NLXqFDYn9dHO/VwZKON95ekdw3YAeiu5GdqD837C9Fbp6ITeI6WoQJh5+DodN6QGaTPSlDwe4OvXMPcJKbd8ybRYCVXhuc16uiH/qIHSGdMoURWvbE7+tt5kkwbB+bjTB8+tOt/SXwCJJYix3vaG2MJAM3jKHsg20HY/F4k9jvPhp4PT1RQB/dk86JPFoisclRHRM/gV78bF3A+vtfap/arx86kVJwmisY4fkhAHfraDpVS//hq1ArJSNgi63yZQ/mEsNJJ3YjkaxWZNoDwUYQKRpnlhpY/U37eJcd3FXZxPL7ySJfMPSYXb31EpCHYbPOiI/h6xp43m0MgRmrj0/46E0qTqj1bp3ML6rqEawFjqaODX6RoapOla4TCL8EHTReZSpFXVNC8WTC/jqFH8zgg1as2sSsNM3sxVsPDKvOiV+AdF80YNRBS9WgnqFORL1MjCHQeWP+8nA3w2ET0brCdl9Z0s8vNwdyWkGLzxmzLUBh82mmgtm5P4odUyC99qvUgTYqwRnsw0qV1n8EeJj9KfPIazspSRmk0S497H/kX6zphwezWrL3Tp1dBGP8NhA/LG5dTgrSzon9H34V4Yki7+nQPcgM57HLb90od1asbBOq+2D19CTkfsuUiJBt8/egx5y8ZnulQJXg0ruRbMC3sylQCemvd3Yr0slhB3pmYlyZ+90HzWod54R/WbfbyfUbl6al6DVqU6Mn2BG/eMj1EcSIIctR4ibN/yxMyVU1x0S9H1CnR9zJ8YsB8ziJRA51SSwu71O40FKm0Wu7pNn4UOzoEtFQaOccj4D4aLVyiQx2b/HBN9yrsNKB+NcJNjwQEirOIDRhx1wtJ qn0Qjqc6 48XN3HHsRPpwfaDeaO1vEemeiorRUMfj0BJAaOSfLWMBBZiizNKb8BpLFfsJVAXFALP+o6OzWfQVP7wiKsYtu2dusu70Jy7sGUdLAIpZQXrDNROKIHbvNDZbU4rCjyjZwDTwo93NHp3XNggyaLmEMGUIbirB5KJAutz3+YoZzvLz+kZQuHGhYoVE5qPFZU1iYr6cGixPQzDvJ78MGUy96AmVt6ZjGoU2WmpqG9aBxFSoDZn1qJarcOgmT0ycHwS3L9nFvdHqIbsQomMAc+17jY1Nc13LYTFo+DGgqmDZ0Ivo0TCXAmJOf61UIInFcDqvPaIXIN4XruJcZbScPkgFfogDyuc6tJA+jgEQ3lg2yWQlysNFiEkJbkTRB2HIkefYzNg8L84z2eZgx8F/CmlOABP85rDeAzx1XZ79ygy4zDCgwdojChWhOJktWk13WXp8F/tdR X-Bogosity: Ham, tests=bogofilter, spamicity=0.157136, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: I like this proposal better. I am still not convinced that we really need internal __GFP_TRYLOCK though. If we reduce try_alloc_pages to the gfp usage we are at the following On Tue 17-12-24 19:07:14, alexei.starovoitov@gmail.com wrote: [...] > +struct page *try_alloc_pages_noprof(int nid, unsigned int order) > +{ > + gfp_t alloc_gfp = __GFP_NOWARN | __GFP_ZERO | > + __GFP_NOMEMALLOC | __GFP_TRYLOCK; > + unsigned int alloc_flags = ALLOC_TRYLOCK; [...] > + prepare_alloc_pages(alloc_gfp, order, nid, NULL, &ac, > + &alloc_gfp, &alloc_flags); [...] > + page = get_page_from_freelist(alloc_gfp, order, alloc_flags, &ac); > + > + /* Unlike regular alloc_pages() there is no __alloc_pages_slowpath(). */ > + > + trace_mm_page_alloc(page, order, alloc_gfp & ~__GFP_TRYLOCK, ac.migratetype); > + kmsan_alloc_page(page, order, alloc_gfp); [...] >From those that care about __GFP_TRYLOCK only kmsan_alloc_page doesn't have alloc_flags. Those could make the locking decision based on ALLOC_TRYLOCK. I am not familiar with kmsan internals and my main question is whether this specific usecase really needs a dedicated reentrant kmsan_alloc_page rather than rely on gfp flag to be sufficient. Currently kmsan_in_runtime bails out early in some contexts. The associated comment about hooks is not completely clear to me though. Memory allocation down the road is one of those but it is not really clear to me whether this is the only one. -- Michal Hocko SUSE Labs