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 X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE4F2C2BA18 for ; Fri, 3 Apr 2020 08:36:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8E7742073B for ; Fri, 3 Apr 2020 08:36:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E7742073B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A3DDA8E0009; Fri, 3 Apr 2020 04:36:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A14D48E0007; Fri, 3 Apr 2020 04:36:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DC978E0009; Fri, 3 Apr 2020 04:36:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id 766308E0007 for ; Fri, 3 Apr 2020 04:36:00 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3621B52DA for ; Fri, 3 Apr 2020 08:36:00 +0000 (UTC) X-FDA: 76665886080.28.show20_8bae2a6ec7641 X-HE-Tag: show20_8bae2a6ec7641 X-Filterd-Recvd-Size: 3802 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Fri, 3 Apr 2020 08:35:59 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id i19so6771519wmb.0 for ; Fri, 03 Apr 2020 01:35:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=GtpPxyoRisktwYV8GKqImVHBqT8VlKdeN8AOG5tsI4w=; b=Hqvgb9EjR0dGiblSsJpyPoWEWBprlN+Jv34npTrOMVwT6MWSUowdeBYSJSYHEKdIKs QW9Td7XSaHeznRAEGLFHSKRz8DtiJSQiprNf7TANCmvfFD6jgz+mX4W7VQfcg8rC20nb S7mttUijWExMkVwAd+eoZv87etSuAcacStUfAkcoEWxBXnb/KSPM3eYfVYxzvNJaL0u9 F/Nqo/ERRo2OvYsB5ofBqmoxmJkRO2IyY+fciUhRjXMzJT/KT1ATCcpgmPjvjN56PwJK O754rVyWuJfJSMNh8cX1MjlN8yLPxxFK/jiBcZte/8lbABSKpng5l+0o3Ws8emKbqb6P eZnw== X-Gm-Message-State: AGi0Pua6r5QjR87psz7sGpBSCOD6ausySzBRw6+w0EXquTmC/Dw/qoVQ Lt1rIxgK0e8JK/dtsOPdcwk= X-Google-Smtp-Source: APiQypKXYZXqpkSNfmPVOPnqf50MiBJus1LGu50LqojrBPE6PAqj6Q97YN1fijOnLAcDh2veZDOdAQ== X-Received: by 2002:a7b:c18c:: with SMTP id y12mr4615614wmi.56.1585902958758; Fri, 03 Apr 2020 01:35:58 -0700 (PDT) Received: from tiehlicka.suse.cz (ip-37-188-180-223.eurotel.cz. [37.188.180.223]) by smtp.gmail.com with ESMTPSA id v7sm11010275wrs.96.2020.04.03.01.35.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Apr 2020 01:35:58 -0700 (PDT) From: Michal Hocko To: Andrew Morton Cc: Joel Fernandes , "Paul E. McKenney" , Neil Brown , , LKML , Michal Hocko Subject: [PATCH 1/2] mm: clarify __GFP_MEMALLOC usage Date: Fri, 3 Apr 2020 10:35:42 +0200 Message-Id: <20200403083543.11552-2-mhocko@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200403083543.11552-1-mhocko@kernel.org> References: <20200403083543.11552-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: From: Michal Hocko It seems that the existing documentation is not explicit about the expected usage and potential risks enough. While it is calls out that users have to free memory when using this flag it is not really apparent that users have to careful to not deplete memory reserves and that they should implement some sort of throttling wrt. freeing process. This is partly based on Neil's explanation [1]. [1] http://lkml.kernel.org/r/877dz0yxoa.fsf@notabene.neil.brown.name Signed-off-by: Michal Hocko --- include/linux/gfp.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/gfp.h b/include/linux/gfp.h index e5b817cb86e7..e3ab1c0d9140 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -110,6 +110,9 @@ struct vm_area_struct; * the caller guarantees the allocation will allow more memory to be fre= ed * very shortly e.g. process exiting or swapping. Users either should * be the MM or co-ordinating closely with the VM (e.g. swap over NFS). + * Users of this flag have to be extremely careful to not deplete the re= serve + * completely and implement a throttling mechanism which controls the co= nsumption + * of the reserve based on the amount of freed memory. * * %__GFP_NOMEMALLOC is used to explicitly forbid access to emergency re= serves. * This takes precedence over the %__GFP_MEMALLOC flag if both are set. --=20 2.25.1