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 54678C54798 for ; Sat, 2 Mar 2024 16:53:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 96DE26B0071; Sat, 2 Mar 2024 11:53:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 91D376B0078; Sat, 2 Mar 2024 11:53:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E55F6B009B; Sat, 2 Mar 2024 11:53:21 -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 6C7196B0071 for ; Sat, 2 Mar 2024 11:53:21 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D3BB71C062C for ; Sat, 2 Mar 2024 16:53:20 +0000 (UTC) X-FDA: 81852694560.17.89115D3 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id F2FCFA0005 for ; Sat, 2 Mar 2024 16:53:17 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=GXVcMWzf; dmarc=none; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709398399; 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=UFN/0TjiqmfLk9k3ExuSBGoIo3YJIBTGV1vH7lZZMpM=; b=2y2SSsFntI5uv1WdhejiGMtgk8q7xNL+0jY950sGDR7dHZgvYZP/K79LnRzI6HB1J0ys8u LdpFnM/8UGqjQyrXRFSjXjZQ0HEDP4tWSurxTfg926d7eQmN1mX+59yz4uCMMxg7PXN+8I m+wxXtxuvUV27xCefVVnTNG34WpsXlo= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=GXVcMWzf; dmarc=none; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709398399; a=rsa-sha256; cv=none; b=mJLcNn7OoNUlXunBTlTdB+y1Hkri8PnvHpuMwTI+9EGx461yC9QzaR0vJ7fc40HhOs0AIE ash5vXqH1ECDBnRbtwN1PuGa3Yi632LKCv+c7/UxgNR1nhq23IWITm+M7CsH5IPnucBa8m zL8yMbm0MgAuma+mUj2sgyGvw70ZXXc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=UFN/0TjiqmfLk9k3ExuSBGoIo3YJIBTGV1vH7lZZMpM=; b=GXVcMWzfibpk1fj4ERagE5xWl8 mQEsFbgHFD8BlBlm68Z5ZaqUwnwRdh7hjqPcjItVuKwdqkeFggyX4vYY/5LLMuRP9VXtidlVXw2yR bb2Fwq7OjbGUeRELvBSUeH9dxX0rfiYdmBP+6APDZhXHgFQY8Q/fHF2NfXxC8X/7aSBw6RTkLovm+ Tt09DXXt5V/Bo0SmpfU4xZTERoGwqPIykiL6h+UyrsGTH83S4GozF7Z5ZZdMTItgEtFIP++pPyZ1U b5MaFHkxOH3KuLNy5u1oF4cWElY27t3z6/c2DPT1AJTR1bURmEhNJ46wzcGR4bjgv7JCYAdi8cdue yrHW7ZEw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rgSbm-0000000E8qI-2l2b; Sat, 02 Mar 2024 16:53:10 +0000 Date: Sat, 2 Mar 2024 16:53:10 +0000 From: Matthew Wilcox To: Tetsuo Handa Cc: Kent Overstreet , 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: <170925937840.24797.2167230750547152404@noble.neil.brown.name> <170933687972.24797.18406852925615624495@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 3su6qoz8bw6zbbey6rxf774q45gzg1e4 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: F2FCFA0005 X-HE-Tag: 1709398397-597606 X-HE-Meta: U2FsdGVkX19RR6leFIptufoPqHqDnlkMJUn8ZSzP0iAF36oYm8uEs9ro0VGZ8WgPYScIcJbDKzb57VGiS+SsQEYNn2l6TEr9VfDgod0DgsvsTauwg3NMavGMWN3855NI7gmPoLzJReMuv4u8mtetW1SNDrP5Lf4GkuiTOKdNsya8+513eRlmajzfyiPWuXcqTEHSoIFf5cXiOj1FydABNXjAaDX0RNvpEPcbb7Cuyk+ZsdlvdTsdzkwq/rVscKe4pqRHv9zzO6VAjjPKp0+eZRz60G1y5bij0Ew+jXX/mMY9A7B7dYmzNhsJ2RHdqAtuM58HmD2OdpYfbPPxhsomcdARm/e1foBVTQYEDXnx6OXLooka7x8BJK1oj7tatI9FgUqZF/K5JgX7DIb/2OvJuALCtfaRnWiuR3Pq1Kp7WJrLU0ErS77WfTOTHU6NMvo7X2PMnAERY15rGvzELQVVtqd2D/KndqMqfGklPrhFA5cUpjZN0uq9mjSu8adaaVMMmMczWrj47maO5dVuNr5yBI3yKiBo2htuP6W6chleeBHmEvIuWFzbIdkCtBSxuRbM/F9OedPeA6jOmReRtv+UOUpCEsVHRmKvlgxbxMOtnF3ziT705Dmq1zl8XpvgwH3ut344pBorkIqobUmevupXADY9bk47nJZda159VS5EUEth2gcRkxwuEqhu7fg8vNXxKjaV5XVVxhOF5H4XGa28BCdV/XGius0jL9wGGVbHI2U4d7fKO22ZClMCtturBQMogc18YWO5tpxVYX34nx1cQ44sY1jGbKy0OFv37QSu+He+2Ib5OsxNuW+/q9hixxNuEV2r3yDrvDt9ZEelcSTbEkm1oo/KGZnzse5T7NxI/QPeWu9TTOdGnT7/87VsEzyGRhDLrpv4ktMC6GNmlDMHX0+dPtcrEwnKxB3VUV5C8IFPj0bHl1UMl9JRfCTHwLCXzNmykDsIJ7WxXc5wa7L rFN34pQJ JYhmtQzJGCk0Vvfsr9vIu1ZhQH2pEELcEeS443ucAAs7IaHf5L7KjtAjIK+edVjx0JtxsmLyBi4bae3qR2Bbd57Lox+imBJUb90t7u2WL78L9cpy6bWATHQYIB2FwgjPjZwd6KrdWAex9hJg= 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 Sat, Mar 02, 2024 at 08:33:34PM +0900, Tetsuo Handa wrote: > On 2024/03/02 9:02, Kent Overstreet wrote: > > Getting rid of those would be a really nice cleanup beacuse then gfp > > flags would mostly just be: > > - the type of memory to allocate (highmem, zeroed, etc.) > > - how hard to try (don't block at all, block some, block forever) > > I really wish that __GFP_KILLABLE is added, so that we can use like > mutex_trylock()/mutex_lock_killable()/mutex_lock(). > > Memory allocations from LSM modules for access control are willing to > give up when the allocating process is killed, for userspace won't know > about whether the request succeed. But such allocations are hardly > acceptable to give up unless the allocating process is killed or > allocation hit PAGE_ALLOC_COSTLY_ORDER, for ENOMEM failure returned by > e.g. open() can break the purpose of executing userspace processes > (i.e. as bad as being killed by the OOM killer). I'd be open to adding that, but does it really happen? For it to be useful, we'd have to have an allocation spending a significant amount of time in memory allocation such that the signal arrives while we're retrying. Do you have any details about times when you've seen this, eg sizes, other GFP flags, ... ?