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 DDA48CA101E for ; Tue, 3 Sep 2024 06:34:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B32D8D0140; Tue, 3 Sep 2024 02:34:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 563418D0139; Tue, 3 Sep 2024 02:34:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42B768D0140; Tue, 3 Sep 2024 02:34:45 -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 237698D0139 for ; Tue, 3 Sep 2024 02:34:45 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CEE3E120A3B for ; Tue, 3 Sep 2024 06:34:44 +0000 (UTC) X-FDA: 82522463688.09.065F255 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf14.hostedemail.com (Postfix) with ESMTP id 1FD57100005 for ; Tue, 3 Sep 2024 06:34:42 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CoNa5ziU; spf=pass (imf14.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.46 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725345157; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Wv8Ur0Meq6UKefyBdzxbNxw7WEZwm6adxFTh2bzlHe4=; b=UtqaFdc9cexFZZguMsfbw1ynSp53KtRw8+4sbGwWB9b4yEjdkxtdYyusEyAqHRULw7kjBK yrwzKpzj6C1a/i7d10RaAXPOI/NHj8DVaxb3DOllGHvtxyAEibO+d8olY0IEGpxJVzpqDA i8AI7kh+kxggD7oKi++ZlQlN1AiWiCU= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CoNa5ziU; spf=pass (imf14.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.46 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725345157; a=rsa-sha256; cv=none; b=hQdaXE8UaMMeSkdJF+ph3kqP6rWl96A3jwmxdoV4ToxJX1rVsLN4nJjSB+dpBOdFAwMz0i G+lYN9PaGRB2MGT00lREHMoMllXaWP9cBj+O5EiKDAuK7asXUmCK6PjmzGAgqYo4h3RoLv HgGm6UlXz+FpwKlOd11mxTGJN8zG1qw= Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-6c3552ce7faso24238216d6.1 for ; Mon, 02 Sep 2024 23:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725345282; x=1725950082; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Wv8Ur0Meq6UKefyBdzxbNxw7WEZwm6adxFTh2bzlHe4=; b=CoNa5ziUZIqOsVQ82gaM1TK8eCke82FOFpBFYOLb6fq/kd1/4GWUykLGu0S6PdtOKC TG/XidjpE7X/zi4VfGZT0zzcfjacXWZls+iyNqt3JH3CsslYczSF1LkbWIMdyZ8RxbM7 5+kjDU7obxBUR+pIuUB1I3rTUzaDMwe9LKL1dl3GqKBvLNeJTU9ppwu/KBqidMCLKMDh 16rkjYZiepFcNnKL5uMqdeRTRqyScjm8R6s5paR7Kn1zC8y2ZKY4ec1Z5x+H7yrkYmn8 dFFgNlWHFLI0l9Wdg3vmdnG2s6PkZsrHqhI+0r3z8zT/9I773OjJnAr4pM/Z0VkcgiVU cKRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725345282; x=1725950082; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Wv8Ur0Meq6UKefyBdzxbNxw7WEZwm6adxFTh2bzlHe4=; b=FkLSPMTOpfHHcGOhwmKXKX1wZ0ygYlreYBAYOrZxoKcbbK9XZVAJZYQ2DIcW1hXhE5 zL96atAnb6oypAzS5r7YhPKL5jqQCkXvLmUm4abSvx4Q+HVDgRddXUWCN7PUiXWSaQ1Y bOiKMn3vgKOapcipAOyZyrxqLxN55pDx5tp9C3O47IZrswHXXDJf7p7hEi4kMoQfq0Jg U5wlk77AO1n/jmBYhDFvsSlJYfZyLXa33mJHzNFWxxTQWCpOv2YH2phgMyoK8u8rFhmR ohMtJ9M2eTbYG2AicaC1pidetnD7gFnr9te7NzN6uZrESPxTyf9OHj4TriCO9PLLwW2F ektQ== X-Forwarded-Encrypted: i=1; AJvYcCWonYyrBH9yDqZuv8tZc19hlRAtyeBpBYS18JngBTNnIBkQG9JsF4xNBEg8+LKMgxNnxwRjPmtOcA==@kvack.org X-Gm-Message-State: AOJu0YwppNBe+WN1wRqox4hz0xUHjDNgDp+/iV4rTa5BFCPq+RDPZjH/ iWul62YNnREUD0H0udRhnBpl2uKddZM+fYkdXvJM3cLemiQN7BQ7ckvu2m3ePKWpdjfL/Gz7M+c a9eitG1VI7qV+z0SVJp7Ut2IhHT8= X-Google-Smtp-Source: AGHT+IHv9LNrpQ60gaO44a46ARNnM3HvLJvdxYBhL9WZNaj42n0QReJ1qZyueALt1fVevYfJBw8qoHdjPn97268yrQg= X-Received: by 2002:a05:6214:19e1:b0:6c3:69f9:fb49 with SMTP id 6a1803df08f44-6c369fa03d8mr67547076d6.16.1725345282103; Mon, 02 Sep 2024 23:34:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yafang Shao Date: Tue, 3 Sep 2024 14:34:05 +0800 Message-ID: Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations To: Michal Hocko Cc: Dave Chinner , Kent Overstreet , Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1FD57100005 X-Stat-Signature: g75h7bobpdxycikyhwg1juj6jtjq14yh X-Rspam-User: X-HE-Tag: 1725345282-120006 X-HE-Meta: U2FsdGVkX18uxWKmmC+SsP6palF+19nMIp0nGOdV6hUxFUu2lU65iaUcOa1/ZAO8AqRkeSdHZ476IB7dTUg1gwSFDO7IciE4Wgv8cf0LxKIbkEg5bpWYywWdYxciV9a+8AOngabAY92ZW+75s974rbeaa2QTtFa5ojlSr+t8ZWEbjbYNykWXQgFhemYyj/v75RxRRgQyN0+SQH+GStmAkh8F0IAUhHpcr9lCrv8bNFwp2WDnXESJ2BM8zWxa65LqAKMqyGIdnODio3NWAdBSaFV1y1RfYk5RP1Ed9Bcd5KilgFSYQ17a8ASGVwXp145vw5E+Q95IfF7zkga6fT2sEu3sPPcXk9W+OsWH4H/41Mxoe8gAi0koA9eE06oc2xr9zpivvMiQ3s9xrKcMgm0pFkQmO11EX8Ju7gAylwwhwVeZLt6pof6QD0FYYXjd4azN47z/n4Xg6Cy5lX+g6C6rKMGjXFaom8bHgHUCXIRVC3zZgcLt6zUSYbRKgPFKoQJC8AE86NNEzjRlmVRxtZrhgtZCimm5bP2sjFJKZEDUznfL3oC9fyuazUNcsAp6d/aKWMCeH6hF1hhwthcAfiMgLCZmhttCab0klYch1tZI94VpdOn5H+y3vvp3IEfeJF9+8s26AeKPrkDA9FdWM3N0HRIghaBf4+G87V6QF1VWrZlZnsb71iJFlxlMMZa8DIe3J5hWklq2L2m2V3iOOzRheNieCoLUAJdoNg+d4oYcEQlheqGag/NzkubV/CgICB2c5HOpfSwHdfmKqbs4Fswk2lO5snnqp/FbnA/B+/+aaZuTSik7f11WJ/UatzWtxktoET838nSof0XF6J7xJNkN5nC9UZK1XatCsE1ZQ78G3rDdSokT+ud8qV7FA052RcuGdbTzbllxhON21Id+gxsk6m+UofL6CKu3A0EojEySZ2AX7fOr3ZsTBmgRKxgV4cnDtr8WLwKz9zRqAAUWtSu LNpiKyzo Rl5dd3cRZ1aX0/cLTfmXE6rtYY2dJR7vsRw1tuBZxmm1Z0w7uVNLzoHUW8c8Pjk3G7tlEVoaxwjdZnIDEsIUbhIoN+r3FTQFJYAfmB1O3I3mrY2W2V4lRn2PrLLYPVaIO60BewSzdolNHizhdU7wB6lY5uOs0rZ+FMs8q4uI04efqHh/eMCAqiKsSddEdkGybV283NZEq3ygq79J4GyvNR1yUfyXcGKt7ZNOLo/LHeErqB97fBwfz3yaQQd3UPszoP3ur7OpLDQPfOcoj15mm1JdM6YPlL3VZo1HghQU1jsfrXeO534yoL5DH//amkuko4KJg/QPOg2SVDclWvN8mFyQ9/+BK0RhwYwtMpeG+/6qHgLwtv4SocHX9B7KmESITslY9SIQ1psC33CffyK9JvMMbXK1S44QziK+wqoXBrHHEfmGEmzLhPJbabg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 Mon, Sep 2, 2024 at 5:09=E2=80=AFPM Michal Hocko wrote= : > > On Mon 02-09-24 17:01:12, Yafang Shao wrote: > > > I really do not see why GFP_NOFAIL should be any special in this > > > specific case. > > > > I believe there's no way to stop it from looping, even if you > > implement a sophisticated user space OOM killer. ;) > > User space OOM killer should be helping to replenish a free memory and > we have some heuristics to help NOFAIL users out with some portion of > memory reserves already IIRC. So we do already give them some special > treatment in the page allocator path. Not so much in the reclaim path. When setting GFP_NOFAIL, it's important to not only enable direct reclaim but also the OOM killer. In scenarios where swap is off and there is minimal page cache, setting GFP_NOFAIL without __GFP_FS can result in an infinite loop. In other words, GFP_NOFAIL should not be used with GFP_NOFS. Unfortunately, many call sites do combine them. For example: XFS: fs/xfs/libxfs/xfs_exchmaps.c: GFP_NOFS | __GFP_NOFAIL fs/xfs/xfs_attr_item.c: GFP_NOFS | __GFP_NOFAIL EXT4: fs/ext4/mballoc.c: GFP_NOFS | __GFP_NOFAIL fs/ext4/extents.c: GFP_NOFS | __GFP_NOFAIL This seems problematic, but I'm not an FS expert. Perhaps Dave or Ted could provide further insight. -- Regards Yafang