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 BFCD2E77184 for ; Thu, 19 Dec 2024 07:18:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D9DF6B00A1; Thu, 19 Dec 2024 02:18:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 48A1C6B00A4; Thu, 19 Dec 2024 02:18:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3520A6B00A7; Thu, 19 Dec 2024 02:18:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 18EEA6B00A1 for ; Thu, 19 Dec 2024 02:18:26 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9A2BE1A1497 for ; Thu, 19 Dec 2024 07:18:25 +0000 (UTC) X-FDA: 82910854362.30.FF9E2BA Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by imf24.hostedemail.com (Postfix) with ESMTP id 7011618000F for ; Thu, 19 Dec 2024 07:18:19 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=KqVd7YiX; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.48 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=1734592681; 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=kws6F4aGXDE2zQGbUn1q8E6/DvmEpDpQpDP0JLhajdM=; b=FJj+5aLZtnB5cDrDw+y46QKKeIxVum4UhSqqrXzq+3gFRICH67oRaBJCgOmtcBZcvc1EWR rOZaT6V6KeuJfFTd/9S6+m3JBLxp/bid+aQPofxw2Uf4HpmWzKm3hvwXzGsS65JhvaodDC uucWJ7Jf4pOmORwFpwQopmRibHBLkCU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=KqVd7YiX; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.48 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=1734592681; a=rsa-sha256; cv=none; b=UV/yLvw59EUl+vZQbNI40C+usNHWgQ0tYtwyfe1XCbH/+kMJxp6Q08JS56sSNP7JGcMLCt /pAW1HH5+f85ccatzJyLc2wmDA2YqKMUC5PJR41Yz7clEsQD/0HTNwFEK+dpyJ3fmhT/WS GXx+JNVKrAaTpDP/VmRavamPi9lrYP4= Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-3862ca8e0bbso298089f8f.0 for ; Wed, 18 Dec 2024 23:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1734592702; x=1735197502; 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=kws6F4aGXDE2zQGbUn1q8E6/DvmEpDpQpDP0JLhajdM=; b=KqVd7YiXz784U8lWNX+fw74e7R7uoaDlR6hXva9EBlLpmuQITmXTQXufldDi65owfJ NiRwAzuJI9lkX66aMYT4oTPrTMTncHknC9BX/mm8/6mjjjlwj6S57XyryZ37/cTpx9Wt QfWMyS765xusWQxKANicTxluJrC2Q8/L1PQj2LH87JSopOQe8pxuys/PMzOTVtlKsq7D ZY/YlVUqbfMdrUiust5Ua5Pf7Ymb7fSVINJZSjLDhI+T36wT4/L/+/OGz3hq5z5U3jFz 7HDe6ms0OMKEEUwgb+PwpeXLqPqDY6RekndvxLxEPBkoNzWJEc5qLWPQ4b+FSOegY8Og XcRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734592702; x=1735197502; 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=kws6F4aGXDE2zQGbUn1q8E6/DvmEpDpQpDP0JLhajdM=; b=pQUDdpRkzvuRgloiCLSSGybg7aC2ZnQuEcMIhPQ8ldxQjxQ0/yt+mpzgxtkM4pVghG X/atmadiE41v76mOxxAyFi3LxSGFAhh6ML1jTTwHihHK3CMQlYyopqgA5fc7Sz40Tlxi 2HELpiuOD1TculaIhsztVFlov5yFuF2dS8msa6pEMg9a3tANcnutD9/sXC4pdEQHeE0p +G8EWAp6HXv6hIQkgJmUpd08X4x+nhiP1Sui9rkIL0/ePp4WWHFEBM4HrrTm0jYD2lpC a9/xTnfoYY8h+BOm7s/CCYAKnv1mznbrmZzBDOCy14+hGXIqP/xtW3Ic4eAHRkOBToHb iYhg== X-Forwarded-Encrypted: i=1; AJvYcCWS88F2c5NX4yMLbPj+DuenQhD6PsAc9wjRk0Qrx0iTmE/0sO7O239PvepNi+BCu5vzJ3FiXHwI6A==@kvack.org X-Gm-Message-State: AOJu0Yz6xalxZxQJ0EOiJtRxPmVq8J/fshbJ259vC47CYnb/hKhtJfji aUF9S53hsXDvSw053hJ3ifXHC3RdwO2rtKoM/Lqs/0v+L+6gE0rrfVHzHXvxBT4= X-Gm-Gg: ASbGnctUWh3PMPdU7G1TPtAMGlmyHExFT9FySg8cYpz3u2CxVXFB+ZCBr57AiJNiyzb AF9TWgpHJpFqwM+zN4YQyvN+8E7J2+1vDu8Wg3LOOO6LU0oex5qdOyJ4/QNl6l1dUlq8f+pSyWn ESMtWToATWE7Qpib0ycsITbiRCcKM0dFS9CltepQyDF4rpGbiemkETUyQ/my0rbJtc/jx8+3ZIA fVziAo8bq3fq/gMsLZqw3NkgDE0Ta6vudXasBYNxjU8F2xdFRPFWJxqhICXG7pd X-Google-Smtp-Source: AGHT+IFoaJwkmK5fLiU8iusoSRP2x655MlL86kCImDrAnz+sbhdizEPk0PkRzRaNgqHEocZ3EndW+g== X-Received: by 2002:a05:6000:1a8b:b0:386:3903:86eb with SMTP id ffacd0b85a97d-38a19b05278mr2083037f8f.23.1734592702217; Wed, 18 Dec 2024 23:18:22 -0800 (PST) Received: from localhost (109-81-88-1.rct.o2.cz. [109.81.88.1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e82eb6asm34457066b.27.2024.12.18.23.18.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Dec 2024 23:18:21 -0800 (PST) Date: Thu, 19 Dec 2024 08:18:21 +0100 From: Michal Hocko To: Shakeel Butt Cc: alexei.starovoitov@gmail.com, 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, 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: X-Rspamd-Server: rspam05 X-Stat-Signature: 4dxsr11zaaqooafr9s76x8amywo8jntk X-Rspamd-Queue-Id: 7011618000F X-Rspam-User: X-HE-Tag: 1734592699-832151 X-HE-Meta: U2FsdGVkX1+7u5vqomSXU2mBLkGMX/gIXICvXEMW5EWRPB14po0wmsxPlNUebhrzDDm/z/on2yxWdkRRPZ3+9rICUuc4Fuuzdtpi021/uExhYXkwos8WNQZtqLYC+qnjLLuwH4/Iq3qrh5v7NzHrR8qj2NJEG72Y+wig9XYxLFWd+WYswhkAN94cplr/8MWVTwQWvu9pcZrb605WZes1nyTFuiBPpk5cKipIXAMvzoPg+jrts+wp8aUsg6Q9m3JFMHLCFFLdqK4+wEN9EXRFiX0As37vsNBjqOYanhl4bptwZlm3/U7ELNeSRxnel85sftQ4EeGvhNsdrVtg8RhAq41Lfs71W1v9lIp/BHQ9UzB7vVQCysGh7LXrteQriDuAT6lxUnPdcQwnXqDl+NWdp53GVXupTnVEyhNkGkQ4IT5hxJL2gAmvOf/KvTzFNwObrlDusnIhNhlm/XbjUqCDZ8tQm0TUNJgpF87dugj0a8Euzl8QZLZpMKE+FRsnWAn5WpVtfnf9sdbWeajSyz2W44Z9OyrqNCPzMr/upTD3RszTHwY/x0bWj5Bp7QDGMDkv9U9VlD72dLCKXIgziPH/WJoWWf2FhWH5Vy9Poahkg9mTlSXtNT3fJyTCW/95neseDB9iVMLauK6A0egToMrcnKJi2xxWkYu0lV1DE0X2RTroQIf/C+/+TDO8MNLX37ojF2A84sggVYQgeTJOH5kQQnBW2dF1KVZ8HJMfJXEIngvF5DD/dRetasADahozPAIqicarRrzrfwmOxob6Az61+8g417qjGQg0iqVUPJVrdHIN2CxRv7aNKQKuHhaplhbvBPOSzEQZEUVaHA9uAUKtcvH0rpxz2Ld4189xZfoNmxoXInBKSTJSNjZ4hFGgKFS1KJnQlUZBA4Al18FMWNMNiHNkZCmNPbC2T0TXIFXXkBPhJwwciJO+mhSrgSdEoWmzE6C12Rq9JxgIFb0bpxW OFLPqMNR bA59eLgQIIOKXNSRR6XnhUDHaDzr05oHOzb2zTp51eFnLZMBuAYdFpQZzf6Kf5/jsS2lOz5QQeFJHyYf/XtgjKEbRMITnnLTqf9rxuZRfBDbPIkuakthB7FiZStTLtVt+ceNApgPzjelbp1Eaqsmox3XGxY5U2AhYbb5DTJc8vnyzBvCpW2lDOaHhN3io+SRjTj0J3zOWT9PeyRjdkbs/pWr+apUna6qOPAn9u7abYs4rj1+rHCaTEIvMvcMcSb3+Rc6aq4RA0GrXMqmWlplmoNa8VQnI+PidTwunpAT+2jTyWpcCG29noPXJAHoSkHu0FP2csXLOW+UskgGEHqYILKKQrYvqF6ZCLAw7/24oTOftaebaDHAp4FRjq1rgHkyVX9RvMOjCuCMiVeMFbHVW10KcnbNf7v2bxywEUl1ZRix2ty/K0YWvyKTEspZZFHJ96+8F X-Bogosity: Ham, tests=bogofilter, spamicity=0.010693, 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 18-12-24 16:05:25, Shakeel Butt wrote: > On Wed, Dec 18, 2024 at 12:32:20PM +0100, Michal Hocko wrote: > > 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. > > Is the suggestion that just introduce and use ALLOC_TRYLOCK without the > need of __GFP_TRYLOCK? Exactly! Because ALLOC_$FOO is strictly internal allocator flag that cannot leak out to external users by design. __GFP_TRYLOCK in this implementation tries to achieve the same by hiding it which would work but it is both ugly and likely unnecessary. -- Michal Hocko SUSE Labs