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 D1588C6FD1F for ; Wed, 20 Mar 2024 19:33:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5919D6B0088; Wed, 20 Mar 2024 15:33:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5415F6B0096; Wed, 20 Mar 2024 15:33:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 408C56B0098; Wed, 20 Mar 2024 15:33:32 -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 322DA6B0088 for ; Wed, 20 Mar 2024 15:33:32 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 063C6C0225 for ; Wed, 20 Mar 2024 19:33:32 +0000 (UTC) X-FDA: 81918416664.16.1AA275E Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf30.hostedemail.com (Postfix) with ESMTP id 29E6F80029 for ; Wed, 20 Mar 2024 19:33:29 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=g9+3i0OJ; spf=pass (imf30.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=kent.overstreet@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=1710963210; 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=4Z2+kj8E7dAZztXoz7TRBvcmNS+JTIHwOPikowIfTEE=; b=ncVpwSdANRKOpFKTukqhnLKYj2OEIPLQ49uQE1RtYBqNNOX/hQuyDZbGn240qg6aT98oEM Ci7g6gHIaeAo7TX0x0jU/grAgpdsO1+VprWbpAF0CLX6pcDmbofLAeNrAo8M5lrZ0pbwXz 8vI5RGH+WyN3GESI86DyDYW01Z0vz2k= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=g9+3i0OJ; spf=pass (imf30.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710963210; a=rsa-sha256; cv=none; b=78i3I5X8V1NDGxrKc+UsfvvZnMnd7perHuYvEq4urv/6zcKcnDn254bAJnqDYQrwzdendN XSP4+6olIfVuUEqfhOgAztBMbAgxiW02ebElBXQ2/CYUUq2ARITxt+Gjd2qARR8tsgJzEm by6ybsHIWTxDaEntE3/BOyUrTN0ZMTw= Date: Wed, 20 Mar 2024 15:33:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1710963202; 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=4Z2+kj8E7dAZztXoz7TRBvcmNS+JTIHwOPikowIfTEE=; b=g9+3i0OJJrgmxAhAeq8rmqn2Wwjk6Gay8gBdl83Tki5UyIDBeoY63LmE6oEDamNJS4utNR 8RKIqITtxfNuktlWZYFMUtvaag9ofsmId5ryGZvBWkZPw/olhPWo8RP3hwqeTQUEnoyrWI 6WtbgoKpWXBEHUbXB7nhvCzco/WRXoQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Matthew Wilcox Cc: Vlastimil Babka , Dan Carpenter , NeilBrown , Dave Chinner , Amir Goldstein , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel , Jan Kara Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU Message-ID: References: <170933687972.24797.18406852925615624495@noble.neil.brown.name> <170950594802.24797.17587526251920021411@noble.neil.brown.name> <73533d54-2b92-4794-818e-753aaea887f9@suse.cz> 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: 29E6F80029 X-Rspam-User: X-Stat-Signature: h5snkbscj8b5z7wghr3g7dpmymcq9ohe X-Rspamd-Server: rspam01 X-HE-Tag: 1710963209-749766 X-HE-Meta: U2FsdGVkX19BVrawf1a8eJNV7E2WAhxZcWxezO+XIFKQs6RLwuOf0/uKfM1OXzoeoLm9h5a7O8OmNRiw4OWOZvf+fe9dmhgc8TSJ0lse9SvXbeIEIDYLh6YvHUDJZZumG5dKEVQRwQIuHLuE+LOLPoakRHrwXryPMocU5s9mdtfVGLPAAPz6lBMHGQJjo0Q5AJc/6tJQSrlEBdBAhHTR5AM6TpG8wCrP4u3Y/8XeBQSCOF07YIwkfv6PYtDm41S19p2HjvK2q6Kd2FOAvwoh4XVTp+co2Uq8aXw0aDC1g9g5DLkOABP/I4v0hQUXqBWTFmjDedGQEigEFIXhT6dYNOGMusnFxW+HjfKQcCy4JVaujq27+gUtxXdLOXX48F/cajecEQqOaIwY9TLXLQhVMqph+Dn/IodZao0QvUYaC3M+sHzl0OkwQB+STkqPM+Dw8MU4sQ29HfZBmKG0jFnlyxzXPf2YbkvvouVufVZaCIOd0MJWrh1AprGXWoHAiukhFmwO6Q6DWgSauPFK44BDY77ho+ro/v1rywq07MqDvkBp4LGeoZktOHutrgJs4B2gq7l7AcJc9o/om53HrtzJcLiG9XtHndtoawWr7xN4969shRKptO7fjDDhpwvA5F401MRnz8Qcf5y3QWB0SrJzCENEJ8yEsNUIJvl7bUkPg3EXXijHe9rv5gMCduiCeqyybbRdKAAFU5WbtNIDELLG1z2H1pELv75qdI3x1HngrexoFNgz1d5bNF8sd6j2nUbdD9Te1OrKPYdVSaijgZPVPs2IINOy7NRLuLDFjky822g= 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 20, 2024 at 07:14:35PM +0000, Matthew Wilcox wrote: > On Wed, Mar 20, 2024 at 03:07:38PM -0400, Kent Overstreet wrote: > > On Wed, Mar 20, 2024 at 06:55:36PM +0000, Matthew Wilcox wrote: > > > GFP_NOFAIL should still fail for allocations larger than KMALLOC_MAX_SIZE. > > > Or should we interpret that as "die now"? Or "go into an unkillable > > > sleep"? If the caller really has taken the opportunity to remove their > > > error handling path, returning NULL will lead to a crash and a lot of > > > beard stroking trying to understand why a GFP_NOFAIL allocation has > > > returned NULL. May as well BUG_ON(size > KMALLOC_MAX_SIZE) and give > > > the developer a clear indication of what they did wrong. > > > > Why do we even need KMALLOC_MAX_SIZE...? > > > > Given that kmalloc internally switches to the page allocator when > > needed, I would think that that's something we can do away with. > > ... maybe check what I said before replying? > > /* > * SLUB directly allocates requests fitting in to an order-1 page > * (PAGE_SIZE*2). Larger requests are passed to the page allocator. > */ > #define KMALLOC_SHIFT_MAX (MAX_PAGE_ORDER + PAGE_SHIFT) > > You caan't allocate larger than that without going to CMA or some other > custom allocator. Ahh, my recollection was out of date - I believe that was 128k at one time?