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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A3ADC46467 for ; Wed, 11 Jan 2023 15:58:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234108AbjAKP6O (ORCPT ); Wed, 11 Jan 2023 10:58:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234734AbjAKP6G (ORCPT ); Wed, 11 Jan 2023 10:58:06 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF24065EB for ; Wed, 11 Jan 2023 07:58:04 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 68A704D49; Wed, 11 Jan 2023 15:58:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1673452683; h=from:from:reply-to: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=RS8PjqU9YFPoIKDDQ9J6v5ILsERDzr/8Ox+dYyD2kcI=; b=FzMW2nfJRIMKMnVBiHF+x+MY9wIHV7E1dybIbBYHmQCTHYQV872cRsIjep8wyZJM/2eL6c /8Jw/j/bjtA4sDn6hsfj8k4bRDM5kgnldGTArOvrAIkyzSOV/Tn6JOQKR/LZDTGcPC2dk1 KeorY/gg7g1//gx68et/J2CwsDr3IkU= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 3E8CB1358A; Wed, 11 Jan 2023 15:58:03 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id /fpADIvcvmOvQwAAMHmgww (envelope-from ); Wed, 11 Jan 2023 15:58:03 +0000 Date: Wed, 11 Jan 2023 16:58:02 +0100 From: Michal Hocko To: Mel Gorman Cc: Linux-MM , Andrew Morton , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML Subject: Re: [PATCH 6/7] mm/page_alloc: Give GFP_ATOMIC and non-blocking allocations access to reserves Message-ID: References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-7-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230109151631.24923-7-mgorman@techsingularity.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 09-01-23 15:16:30, Mel Gorman wrote: > Explicit GFP_ATOMIC allocations get flagged ALLOC_HARDER which is a bit > vague. In preparation for removing __GFP_ATOMIC, give GFP_ATOMIC and > other non-blocking allocation requests equal access to reserve. Rename > ALLOC_HARDER to ALLOC_NON_BLOCK to make it more clear what the flag > means. GFP_NOWAIT can be also used for opportunistic allocations which can and should fail quickly if the memory is tight and more elaborate path should be taken (e.g. try higher order allocation first but fall back to smaller request if the memory is fragmented). Do we really want to give those access to memory reserves as well? -- Michal Hocko SUSE Labs