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 6B11BC3601B for ; Wed, 2 Apr 2025 23:10:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08B3A280003; Wed, 2 Apr 2025 19:10:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 011A2280001; Wed, 2 Apr 2025 19:10:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF5B7280003; Wed, 2 Apr 2025 19:10:13 -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 BE510280001 for ; Wed, 2 Apr 2025 19:10:13 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6FC881CADF1 for ; Wed, 2 Apr 2025 23:10:15 +0000 (UTC) X-FDA: 83290649190.28.9F7C0DF Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) by imf17.hostedemail.com (Postfix) with ESMTP id 7D43840004 for ; Wed, 2 Apr 2025 23:10:13 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=oHzJphOF; spf=pass (imf17.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.173 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743635413; 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=LQmokx6Rzrba+kqyKTeF3C/N0r3WG9zBf0JGb6uUwnA=; b=KaSU2UoFDz7onBZYR7WyeiqmIZ7xRvThz2utGr/og/1xSIg97L+/SDVZhCvJ6nel3I+KJX nw/+Q/c/CO99UZdQ+5oJExRo3NqQpsEbJn8KEkSkCIy+kJK3s2gFotlKcrezhXQAZWaUaI B6C2H8QiQ5iOMc/qMalQ+1OgQeRZMDE= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=oHzJphOF; spf=pass (imf17.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.173 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743635413; a=rsa-sha256; cv=none; b=miHVUoO7S2DMLL3CWrgNXNr0MrTukSO2+j63cQWQGt5RzvJtCFzBnYvjyzPQ+m6yzHMUGU bfQ33rKEfibz6lUp0I51Zmjrke2aKdEQKJEbcw8GrSCg0eg5wcRC1KsxJKjoBCdm5SpjUT l6FGisiF2F9ATJn0XkflfB/IrwKZhOs= Date: Wed, 2 Apr 2025 16:10:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1743635411; 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=LQmokx6Rzrba+kqyKTeF3C/N0r3WG9zBf0JGb6uUwnA=; b=oHzJphOFyUFATELdREX2cGOk0OBVZWQ8ZI28+8TjnKNSqGGuTFtPk0k2flq2xYpSz7jtcS CNpWZwJb7sOSIfUuImj1P/dTorBxzVB5cwF+wdiC9LS/DeELwM3H5TxVVYyrxzzBsQfQmR knDEKvvnkfJOWGG8ToFzliDiACvY94o= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Dave Chinner Cc: Michal Hocko , Yafang Shao , Harry Yoo , Kees Cook , joel.granados@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Josef Bacik , linux-mm@kvack.org, Vlastimil Babka Subject: Re: [PATCH] proc: Avoid costly high-order page allocations when reading proc files Message-ID: References: <20250401073046.51121-1-laoar.shao@gmail.com> <3315D21B-0772-4312-BCFB-402F408B0EF6@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 7D43840004 X-Stat-Signature: n4ac1gzu151bo6cesxu9y6t1zoku66uj X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1743635413-905316 X-HE-Meta: U2FsdGVkX1+ixLrQ+tRgbj8CdUm+RfPGO1VNVTzAKmc5ZxdOMahInoTSxeKNMY8aHA7VjoB2HKfgjyaDAODNUkCEl7MRx1/n8WSw6b/twxuCK0m/j5D6osfClzD0dmi+wyGc6JkFK8v1bd5v9UiEkrfVKG+dLIDw5JQB222wlUGPEEX4RiuFWbydnnko5Y1BfYR9bOIrIDm0as3BEV4gxKkxqG0IZXX7rZ9DpMn5ax8dptmKuXDWSUYR6jf518dduSyJWSgcubPuOxzwwek8VU8WaPZsHZTS2k+Vk4z5KIgKWUkwxPNTWBLAhmXiKILkPy9+lJBgoT0SsImlR6vRuI/xmeQCjtLM8k5n8FSF+NpxVs19FQ60ji9IvssxivpupFnRTW0D/mZqVesQP4Q20/3AeAA+udxCoxORgnG3rRfRna9DKBvp19TsgLVwH5w3obJW3LIL2avqvwh/tu/PIzVHhXGlXm2fo853qo+V4GWeBjdY4+EOINRMP17fpAUz303XJK6U8CG32XJ6oEYRwMVwrK1xIFezR0AlLj7fOyopElhNsf871tx0d/vO57YNDVBozQsV6DCP1cdeDKdCKUmhSG8+FPFpQZEXIhLbfP3H0SVIZ07YszLKydA7f5303hLuN43M5PVD6lgEkbd8ixGr1rtX9INsuggAwSkeldZogR24xhDlLfc4KefxSTVBwyUUFGJ+t0lY3gHEIQW4wV2MZdPMQzedKylTb7OR7yUO6xvJmb8+0nEa3uB2qSFGkMKKEfScymT86NU4UM1su4OzwQa9BtnNeYnSYD3bhaJAPu235sFaCfE9TGqf2jKnEzRCgLHtS5FyOJ6xBnqUyQ+7bCQlgLmYELA4zy4iWKlLOkAdqNqNcaewX+70FvTuiQBC9zxavqwbHpxbuDy7V+cxs55rFAd+JcN2OrPLHzMf6OssyBIu7f8WqNWl34z0XUpWaKVXbuk+elA9clV 4wcqLn6s oB6GDJ5yEmbO5+Xn74yyPqQPYdoIvUHFVRwzAOEVM5aEtoU+qz/oRIBtdPpALx9LhmcDlLuAWyMK7frRNfFlWRL2mY6SU0M+z9jtdLo8ohEA46cTEzSEzeoUA0u+qFhx0WKCcYbXuxWPmC2XAlpdnNCx7kpZS9R2pBwgmrVonl+V538TXyMQfclxPhHPlBWXL/41MpoKh0u6cgI0FXW1DlM8kque3nEVYcquvnEK9YEsVyoGso4une2RWZ4FDjZ0JbjGQmwkpHWJRdXWMy1J3vINz4T3E6lpd6uiY5Z2OS7OLumVMfxD6O2Uy3w== 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, Apr 03, 2025 at 08:16:56AM +1100, Dave Chinner wrote: > On Wed, Apr 02, 2025 at 02:24:45PM +0200, Michal Hocko wrote: > > On Wed 02-04-25 22:32:14, Dave Chinner wrote: > > > Have a look at xlog_kvmalloc() in XFS. It implements a basic > > > fast-fail, no retry high order kmalloc before it falls back to > > > vmalloc by turning off direct reclaim for the kmalloc() call. > > > Hence if the there isn't a high-order page on the free lists ready > > > to allocate, it falls back to vmalloc() immediately. > > > > > > For XFS, using xlog_kvmalloc() reduced the high-order per-allocation > > > overhead by around 80% when compared to a standard kvmalloc() > > > call. Numbers and profiles were documented in the commit message > > > (reproduced in whole below)... > > > > Btw. it would be really great to have such concerns to be posted to the > > linux-mm ML so that we are aware of that. > > I have brought it up in the past, along with all the other kvmalloc > API problems that are mentioned in that commit message. > Unfortunately, discussion focus always ended up on calling context > and API flags (e.g. whether stuff like GFP_NOFS should be supported > or not) no the fast-fail-then-no-fail behaviour we need. > > Yes, these discussions have resulted in API changes that support > some new subset of gfp flags, but the performance issues have never > been addressed... > > > kvmalloc currently doesn't support GFP_NOWAIT semantic but it does allow > > to express - I prefer SLAB allocator over vmalloc. > > The conditional use of __GFP_NORETRY for the kmalloc call is broken > if we try to use __GFP_NOFAIL with kvmalloc() - this causes the gfp > mask to hold __GFP_NOFAIL | __GFP_NORETRY.... > > We have a hard requirement for xlog_kvmalloc() to provide > __GFP_NOFAIL semantics. > > IOWs, we need kvmalloc() to support kmalloc(GFP_NOWAIT) for > performance with fallback to vmalloc(__GFP_NOFAIL) for > correctness... > Are you asking the above kvmalloc() semantics just for xfs or for all the users of kvmalloc() api? > > I think we could make > > the default kvmalloc slab path weaker by default as those who really > > want slab already have means to achieve that. There is a risk of long > > term fragmentation but I think this is worth trying > > We've been doing this for a few years now in XFS in a hot path that > can make in the order of a million xlog_kvmalloc() calls a second. > We've not seen any evidence that this causes or exacerbates memory > fragmentation.... > > -Dave. > -- > Dave Chinner > david@fromorbit.com