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 F4027CD5BC8 for ; Thu, 5 Sep 2024 14:12:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8351D6B0105; Thu, 5 Sep 2024 10:12:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BCAE6B0106; Thu, 5 Sep 2024 10:12:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 636C76B0108; Thu, 5 Sep 2024 10:12:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4598B6B0105 for ; Thu, 5 Sep 2024 10:12:59 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BBAFC160480 for ; Thu, 5 Sep 2024 14:12:58 +0000 (UTC) X-FDA: 82530876036.11.32673EF Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf05.hostedemail.com (Postfix) with ESMTP id 61EC0100025 for ; Thu, 5 Sep 2024 14:12:56 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CXw+SNBo; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725545479; 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=gwYsBihYTyfOkMwcrQ2PgVwPBmg+Ta54Eew3ioB7SiQ=; b=bv1+6wBPtV3ffhC7Fja4Hsb1g2xh7jVaIE6MT7OQLiG9OGy9L18++ZhLmsV3hRyMyU57Hq 0G5IlRgjq2o2i9KC9MBGwpvDs2hNsQTWaGk8Ybcbj1/DHNWR1Wk9M88hg5PjeEb7zYglmF FXqHP+IfXPJWH2i6qMbqThLW9kTqK5M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725545479; a=rsa-sha256; cv=none; b=uFNmwVFXCZQVnQrgZIFtiRgH4rKEEM9U5njzt85KGoDHAZFDXqM/NtL4XMHB3x4AxMU1Qg wfuM1LO/11ULWg2klX566CUN8SsPSbyMVQPvM/yAAX9dpsCdpXhjP5rcNoLS41yy0HHbmE YHXA1/0g5m7L5wsD8V8aOLnE3nhQGbc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CXw+SNBo; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-5356aa9a0afso1405640e87.2 for ; Thu, 05 Sep 2024 07:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725545574; x=1726150374; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=gwYsBihYTyfOkMwcrQ2PgVwPBmg+Ta54Eew3ioB7SiQ=; b=CXw+SNBooRJ9v2kBEMXlNzXjcxUmbVBXfL9G4kGPqlsCrU/OC95FEQjEPkAEFUl4gQ BUW2iE7U2KrpLdz5yv3jDh2uJsmW17PkWofgoOTAYGw/lezxEXoM1StJNlp6X/W832ch lImECp0mU+OK6ddug9mdP1FvfFLv0XphzKJb6haXMNA+YHEDMIeVTdrEoekXn8phfoiZ MvCmTfxNkZICH8xZowVPI3Va2ScqhuERtb4qXS/LHqWE364/uKf9RWZkBbZ75Ejq4IVG AfAkzw70UalVPqbCX/fsM9rcI78dCMU0Ur36CYAnEXHoh4b1jHaAlp9Sgr0BHyDiFv4f R6GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725545574; x=1726150374; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gwYsBihYTyfOkMwcrQ2PgVwPBmg+Ta54Eew3ioB7SiQ=; b=qP9nYBDQJpro98KZpTmAxs0ybGWfGTTqME9P0UxQ8MR++JUuArLY1RFQQXq33lP6NY vb9hc7wrAVW69ftCZyrno8uUF+oG5xU6ZAubNTDd4c6y5MCYYHB5s2ECkssggEa8dd1D Gmt5m0S5bqPJSX7gC3cIobuDDjUWG9jrzWO/Muf8AAor+mXHtFLs7CfRw/uIQr7qcNak GFI/KRmQWRyZi+MBVgfBt+9EBAiuLTNgBmsoz1eqrK++rzm0KUUvHmS9u6dCaicM1p/9 ifa5a9x4HuRjs/SieJFiXfb0NKwVThCPU6OeDJuLlP0fejb3kQiKYsHbBwt2+TUX82p4 sR8g== X-Forwarded-Encrypted: i=1; AJvYcCV0DfhzsnM4zAf1Y1mpOBKye2QEfvsJJQB1W5csEfNQBsUrpFtsKC2u9Ugs1kfRoMy47J44MS5Hnw==@kvack.org X-Gm-Message-State: AOJu0Yw2F5wMm///UfG2qtSkhQTBfi84geaeUxM1LiR/C/ieoldV1xuy dmWKjAfYArD8NPCdZpqiUriAw6O7XxJrqDKS3RryfdTzDAQs24NJYqLne/kAZQE= X-Google-Smtp-Source: AGHT+IGsTyoQo5r21FHK64nbduDdB0RMk5Y4ciVDsCqSQ9O4YP1mPL/j+bbkh4RnUZCAoKKWGupTJg== X-Received: by 2002:a05:6512:a8b:b0:536:54ff:51c8 with SMTP id 2adb3069b0e04-53654ff53dbmr1077754e87.17.1725545574270; Thu, 05 Sep 2024 07:12:54 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8a623c2fa2sm142182366b.183.2024.09.05.07.12.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Sep 2024 07:12:54 -0700 (PDT) Date: Thu, 5 Sep 2024 16:12:53 +0200 From: Michal Hocko To: Theodore Ts'o Cc: Kent Overstreet , Andrew Morton , Christoph Hellwig , Yafang Shao , jack@suse.cz, Vlastimil Babka , Dave Chinner , Christian Brauner , Alexander Viro , Paul Moore , James Morris , "Serge E. Hallyn" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-bcachefs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM Message-ID: References: <20240902145252.1d2590dbed417d223b896a00@linux-foundation.org> <20240905135326.GU9627@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240905135326.GU9627@mit.edu> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 61EC0100025 X-Stat-Signature: 81m8nnngpmwc3t1mybmuw7pdhxoe94da X-HE-Tag: 1725545576-449741 X-HE-Meta: U2FsdGVkX18kZMxiWEnryi2KUf+nkjTCjNHoTekox/UTL3BhxlAOcD+kJHi28kuc92XeX+IIsnI+4aemhJlGfSRlhFxLXKUCV+0Nr9wrcuxEDEpo2AjS7p2a4Og5qXcrEMoxP4QzV9tfiZD5P0y16p4YFq17jV/HWIJNIxtyX3hwJmS8MyKlG6ncJlrD95A6ExZtkSBzRhEibOzp5FsNpLkt/N7qJtiTfSx2fFBjdX6/bvh1wR7TOmk8b+I1mWJ7fXzyE5Z/oZqho9VFiPcJXJdXzR/+D/uExRfMc9jDHcKdN62y0ulmVHyUFLH01tO1KRlD6Gp2Ct/ov0mgDW4pDH409vmtK8ExmyE7EHz+U0vcRUhpLnRKiTlX76mdACKIIen4lGP1gkPJIgu98nqBadXg3MvQ2H8gSF26KiU1txVVWAJrqgG/0eMBrrPJjgPPoQsxxMrVPr7ew6X7SheSJWLKuI6nsy4gIPeTTUQ0sKipkT5+/ksIlhs6G1aSEUx6pWmyZZNUm/RzptJbeZKduOfy8gZgyDuJwtreXVYgb+cL+s6IsJpjUCaYIp8p40xCnDBYhm8O7CFIfJS7SsHr6F4foWLDuyNW7cLdl8ybmmVsw8kmVeIwekiN+NOLx11MWrWh1B+a/gKSm1gtIwYkBn64jvUQL+RDxeoNd8xu/XADcFuyTYcMWA96ALH17gdESv/0S92KOrgI+T2HxVc+sh9Om95C9R42L46CQchGv3JtqYxoo0+RMpFAde/4CyAaIazjXsGCXV2SrgmsLgID2W+4gN63+c9FtccNrAG8ONtF3IkFjvjLL+3fHFrK2B6fQTXUrWhnpgRBpQlRdLeghslgJDwjJ7ojaEJmZQbP0R7+VuynN2KMWEtpYKGHYC99ScwlWxEMhMBN6yvz2eOZuJzy1JBt43FlRyXo2HKY5CaeGhRqIkt+c2pyhb8n2KRfg38Z9b+wppqB7pJer9U Lw6O5LhF 8b5jIO7R/YD7TcTAHjqpHP6HTTfpolJDWHMvxTX8i8+JDfe0MB8EAZAu3/nMUbbxDCLYYanjpCLb9BcLjZPK5ddfvFz1PL5AiZ6fxAEiVsgulhX8wS1oFIQHcSPAKmqM1MJHZ6Pg1gHbddTm4AotLXh6c2YwMXj2Wv56cU/7KO5kmBJ2ckp+sJIp4SJhaM+nKVzw9CabRvrywBqKEeWqYxOL3LrMPPPNXijs1HQ9SWxyIFsncv4gIJcljiOME5UGTsCrFRmPdBBYOftAXtgOle1SDB+VGsr0PgEZEMdnY1c8urmpzfz5AxzpfYR9Y8dIUNfyBZWECf7iEedVV759qh8Jhxr58ESmxSnWy+zGhSUCElLr4eFNWj/8ieGY+kmTD3GTGG2//8EAndHBBNuihLi6VWlNYTW202sKBBJD+GtnxT0hDAGuKvvxLPw== 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 05-09-24 09:53:26, Theodore Ts'o wrote: > On Thu, Sep 05, 2024 at 01:26:50PM +0200, Michal Hocko wrote: > > > > > > This is exactly GFP_KERNEL semantic for low order allocations or > > > > > > kvmalloc for that matter. They simply never fail unless couple of corner > > > > > > cases - e.g. the allocating task is an oom victim and all of the oom > > > > > > memory reserves have been consumed. This is where we call "not possible > > > > > > to allocate". > > > > > > > > > > Which does beg the question of why GFP_NOFAIL exists. > > > > > > > > Exactly for the reason that even rare failure is not acceptable and > > > > there is no way to handle it other than keep retrying. Typical code was > > > > while (!(ptr = kmalloc())) > > > > ; > > > > > > But is it _rare_ failure, or _no_ failure? > > > > > > You seem to be saying (and I just reviewed the code, it looks like > > > you're right) that there is essentially no difference in behaviour > > > between GFP_KERNEL and GFP_NOFAIL. > > That may be the currrent state of affiars; but is it > ****guaranteed**** forever and ever, amen, that GFP_KERNEL will never > fail if the amount of memory allocated was lower than a particular > multiple of the page size? No, GFP_KERNEL is not guaranteed. Allocator tries as hard as it can to satisfy those allocations for order <= PAGE_ALLOC_COSTLY_ORDER. GFP_NOFAIL is guaranteed for order <= 1 for page allocator and there is no practical limit for vmalloc currently. This is what our documentation says * The default allocator behavior depends on the request size. We have a concept * of so-called costly allocations (with order > %PAGE_ALLOC_COSTLY_ORDER). * !costly allocations are too essential to fail so they are implicitly * non-failing by default (with some exceptions like OOM victims might fail so * the caller still has to check for failures) while costly requests try to be * not disruptive and back off even without invoking the OOM killer. * The following three modifiers might be used to override some of these * implicit rules. There is no guarantee this will be that way for ever. This is unlikely to change though. -- Michal Hocko SUSE Labs