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 96F4BC48BF6 for ; Fri, 1 Mar 2024 03:10:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F5F46B0083; Thu, 29 Feb 2024 22:10:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 07DF26B00A9; Thu, 29 Feb 2024 22:10:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E60C2940007; Thu, 29 Feb 2024 22:10:14 -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 D377A6B00A8 for ; Thu, 29 Feb 2024 22:10:14 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7707840262 for ; Fri, 1 Mar 2024 03:10:14 +0000 (UTC) X-FDA: 81846991548.02.53F1739 Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) by imf13.hostedemail.com (Postfix) with ESMTP id A161720006 for ; Fri, 1 Mar 2024 03:10:12 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VymsT+Zp; spf=pass (imf13.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.177 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=1709262613; 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=C1H2jOGnASL5yJnW2d++8ehyB71UlfbyZz1T0lnOHuo=; b=BljsDyKcoqNyWZpKeMs4uLbgTBcXBftZzp39tRtNbhVELSLxaB8gvUT+M4nfsC946Aim3e I3W6Qdwlb5WgFmLgW4ZBt+KKbDJOpdutI1BFR2pnm45AOCHnshjpx2op9m51S87mUwnq85 rNm23YqjcF5ht3nIDqEKhb7kai2rLHE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709262613; a=rsa-sha256; cv=none; b=NXc+06NH98DoFKxmmege33CWnpd12BAk9m5FlA3TBPR0q9fvfSy9BQC8pM0hMd3pMYSalb bI1KkmkzbD/0n5MsqDb/rTiYkXZBOsZ8ObPlGnCTCnLxlWuoJ78lecfI4/EShAx7b9FaV3 dA7bh3YNsDNMdNNCiW/Zq77q0Hmf7C4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VymsT+Zp; spf=pass (imf13.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 29 Feb 2024 22:09:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709262610; 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=C1H2jOGnASL5yJnW2d++8ehyB71UlfbyZz1T0lnOHuo=; b=VymsT+Zp3zdR1qRlgK1Op86nDz72vFwUg/GSB21aax9A+k2xTJL0nsbrwCcPWVUJlCWyqs 5yvJyVlozCRGBWbnBVK41k4QJu95zR7B8MG1Y+H24+p5/COjQZzVEIUpDCwfBnTSy85HsU NtJSHWoVaX/TASvyG6U16yWYi/k2ils= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Matthew Wilcox Cc: NeilBrown , 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: <170925937840.24797.2167230750547152404@noble.neil.brown.name> 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: A161720006 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: uz3kahso8otut536ow1hw6tpjtwaosfg X-HE-Tag: 1709262612-733265 X-HE-Meta: U2FsdGVkX1+a+9waLjCJahOn7EqXMLU16iwhdxEkysxNNaOMLmMHEUk1buQJlZGViuRyiqu9Bk1r9FdziPfHoUxJ2gu0s6Svoo8P13ZVT8n/16DUlTZ7l/r2KX16xD6qBRRj58IKr43dhf9quwLrVb6d3a7f6saQWbdflk5jchoksbQXxO2Q9tN/9G2B6o7p0Qq/kgmu2OBzKjYVs9QE1JmDf6aschacafylQC9eUshlobVlC5InIF+nBoSC4MiYxT1oiqoZL29ui1Z2nt2T8vTwJgPVaO6zsGKsaTE21ooPIr2MltXp6lWg44YkgcgGMmqEXbXq0gZwSgIp7g00HB8I04fxISQw7X1qwuwONdAqzJ73j1CKwbW0g4xbOEq5r/b5mHK+IhbVFSdz/21a4BMuwejAe3GMB60gC8nKHYAI5HV+Tk31ELsPbAAZ3znmH+jSFHZZRgl89A8qZHrp4PygwbApaHZwzD3O5Q2KChZISKja3ycASdzVxHSBTHFrU6pGKDxIvBEe37Js6NIYQmsIKLrU+seFUM2j0wT9/lJ+/EPAa0+qSzbgLUFCcXwxaWTDDEYenXZoIbW2cIJ39KQMonWz926qfvaQN6S1qkm77i0upoSDvd0o1BNV0LA3yRdF+Z0ZHv2digJIlJAGR14YbTqwn3Ux9G8WVk70B9/2CbkMrD2QH78uv8IhT3beFsFSIhPXmqHHh1gbu1WwhLlEBlkyhxJVEaUPl6DG+aHNr2BsFIT7X5BsK5v8MRfeEP7rvB165PHLKeaBsDEH1aSpApdt+zUsD0AoiEIoWnQ= 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 Fri, Mar 01, 2024 at 02:48:52AM +0000, Matthew Wilcox wrote: > On Thu, Feb 29, 2024 at 09:39:17PM -0500, Kent Overstreet wrote: > > On Fri, Mar 01, 2024 at 01:16:18PM +1100, NeilBrown wrote: > > > Insisting that GFP_KERNEL allocations never returned NULL would allow us > > > to remove a lot of untested error handling code.... > > > > If memcg ever gets enabled for all kernel side allocations we might > > start seeing failures of GFP_KERNEL allocations. > > Why would we want that behaviour? A memcg-limited allocation should > behave like any other allocation -- block until we've freed some other > memory in this cgroup, either by swap or killing or ... It's not uncommon to have a more efficient way of doing something if you can allocate more memory, but still have the ability to run in a more bounded amount of space if you need to; I write code like this quite often. Or maybe you just want the syscall to return an error instead of blocking for an unbounded amount of time if userspace asks for something silly. Honestly, relying on the OOM killer and saying that because that now we don't have to write and test your error paths is a lazy cop out. The same kind of thinking got us overcommit, where yes we got an increase in efficiency, but the cost was that everyone started assuming and relying on overcommit, so now it's impossible to run without overcommit enabled except in highly controlled environments. And that means allocation failure as an effective signal is just completely busted in userspace. If you want to write code in userspace that uses as much memory as is available and no more, you _can't_, because system behaviour goes to shit if you have overcommit enabled or a bunch of memory gets wasted if overcommit is disabled because everyone assumes that's just what you do. Let's _not_ go that route in the kernel. I have pointy sticks to brandish at people who don't want to deal with properly handling errors.