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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 88A12C433FE for ; Fri, 4 Dec 2020 16:09:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4BEE12223E for ; Fri, 4 Dec 2020 16:09:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730748AbgLDQJJ (ORCPT ); Fri, 4 Dec 2020 11:09:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727425AbgLDQJI (ORCPT ); Fri, 4 Dec 2020 11:09:08 -0500 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66D7FC0613D1 for ; Fri, 4 Dec 2020 08:08:28 -0800 (PST) Received: by mail-ej1-x642.google.com with SMTP id qw4so9384695ejb.12 for ; Fri, 04 Dec 2020 08:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AgJ3P5TSBGZilokHFX8v5OKRIwn1E+p9CC+Sd10NgMQ=; b=LK/Ok/J7yG5aJDlJu3t4ObQmoWk9vv1x4VKKVqhoqZ6Rp9H41TAXFWtXqWaRmZGG6c +of8NdIYflycxa9MMZwjUWNVSDU4ZujAWKT0Bsh8pv2N/O2A/ypIiwUzljXRPgQHntZb AVw3LQb/yaP2aLSkRDX1uoDwzbTNnifaheWIVSN5FLXFszfCpjoeDnl3nkmu0Svin0GT xsToUnZa2J3mOjlFUkF3eJILBjMtRWC2GKZmHOdon8sHNsg6CC8kOLTNRtx6RToaVqAM kURXO187jDRswd2iE64ufKBM1W4Cg8Ry/tWS8EnFTFjvY2+E1RfwpyaROJDyhJIeq/xN LTQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AgJ3P5TSBGZilokHFX8v5OKRIwn1E+p9CC+Sd10NgMQ=; b=or8DyD1YeIOjEmsq4uC5wCJyXhmvn5jQYeTkG7wwhf4WpAtrnedndt+QKlBDs9+kEj t6AAyEMurnP8OKKh6xx2rPSCr1eAVgmf13mXHKLsUQGJobTY7fIQunIbxkVJ10s6X52o JeFOkSYQSfYfQWbTAfa0WJt0l2jPr7+J/0zcz+bpahROG9JVoGhFYWv6jDnSO+saJucY vtaj5V7n1q8kvXMDTIcdcsX9MmZLEBo/KnW1qBOzhzsZMYUqG1yyoJ8PIR/4Kuarv2rS KullOtP4uGyRsJzYAu1Aail0IO1/ttEytS4Ripoc96/w5Su1VxEM712xFXWiAPKukTxF xM2Q== X-Gm-Message-State: AOAM531lzzTyaH5k5szYwf/HI8/nEI3ECuplPpHg+b+bmpzJm3od8B0u 4eYJI8vxzGqRb9QWhiiwk6vj7eeNAW4gva26wdswZA== X-Google-Smtp-Source: ABdhPJw///BFE4BaSY8UnV6aE0C4WBjQc/DC3TSJISHaKAazmCia7ZOh3/BZ8cz1zZ13sXf8TG/iQdUxReSmgKICNfE= X-Received: by 2002:a17:906:fb9b:: with SMTP id lr27mr7997127ejb.175.1607098107080; Fri, 04 Dec 2020 08:08:27 -0800 (PST) MIME-Version: 1.0 References: <20201202052330.474592-1-pasha.tatashin@soleen.com> <20201202052330.474592-6-pasha.tatashin@soleen.com> <20201203091703.GA17338@dhcp22.suse.cz> <20201204084312.GA25569@dhcp22.suse.cz> <20201204085401.GB25569@dhcp22.suse.cz> In-Reply-To: <20201204085401.GB25569@dhcp22.suse.cz> From: Pavel Tatashin Date: Fri, 4 Dec 2020 11:07:51 -0500 Message-ID: Subject: Re: [PATCH 5/6] mm: honor PF_MEMALLOC_NOMOVABLE for all allocations To: Michal Hocko Cc: LKML , linux-mm , Andrew Morton , Vlastimil Babka , David Hildenbrand , Oscar Salvador , Dan Williams , Sasha Levin , Tyler Hicks , Joonsoo Kim , mike.kravetz@oracle.com, Steven Rostedt , Ingo Molnar , Jason Gunthorpe , Peter Zijlstra , Mel Gorman , Matthew Wilcox , David Rientjes , John Hubbard Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 4, 2020 at 3:54 AM Michal Hocko wrote: > > On Fri 04-12-20 09:43:13, Michal Hocko wrote: > > On Thu 03-12-20 10:15:41, Pavel Tatashin wrote: > [...] > > > Also, current_gfp_context() is used elsewhere, and in some > > > places removing __GFP_MOVABLE from gfp_mask means that we will need to > > > also change other things. For example [1], in try_to_free_pages() we > > > call current_gfp_context(gfp_mask) which can reduce the maximum zone > > > idx, yet we simply set it to: reclaim_idx = gfp_zone(gfp_mask), not to > > > the newly determined gfp_mask. > > > > Yes and the direct reclaim should honor the movable zone restriction. > > Why should we reclaim ZONE_MOVABLE when the allocation cannot really > > allocate from it? Or have I misunderstood your concern? > > Btw. if we have gfp mask properly filtered for the fast path then we can > remove the additional call to current_gfp_context from the direct > reclaim path. Something for a separate patch. Good point. I am thinking to make a preparation patch at the beginning of the series where we move current_gfp_context() to the fast path, and also address all other cases where this call is not going to be needed anymore, or where the gfp_mask will needed to be set according to what current_gfp_context() returned. Thanks, Pasha 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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 35F45C433FE for ; Fri, 4 Dec 2020 16:08:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CDD69227C3 for ; Fri, 4 Dec 2020 16:08:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDD69227C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 636A86B0074; Fri, 4 Dec 2020 11:08:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BFD06B0075; Fri, 4 Dec 2020 11:08:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AF6E6B0078; Fri, 4 Dec 2020 11:08:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0064.hostedemail.com [216.40.44.64]) by kanga.kvack.org (Postfix) with ESMTP id 326D66B0074 for ; Fri, 4 Dec 2020 11:08:29 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E9539181AEF1E for ; Fri, 4 Dec 2020 16:08:28 +0000 (UTC) X-FDA: 77556082296.22.quill81_5f17e8e273c5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id B65D318038E68 for ; Fri, 4 Dec 2020 16:08:28 +0000 (UTC) X-HE-Tag: quill81_5f17e8e273c5 X-Filterd-Recvd-Size: 4811 Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com [209.85.218.65]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Dec 2020 16:08:28 +0000 (UTC) Received: by mail-ej1-f65.google.com with SMTP id jx16so9395972ejb.10 for ; Fri, 04 Dec 2020 08:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AgJ3P5TSBGZilokHFX8v5OKRIwn1E+p9CC+Sd10NgMQ=; b=LK/Ok/J7yG5aJDlJu3t4ObQmoWk9vv1x4VKKVqhoqZ6Rp9H41TAXFWtXqWaRmZGG6c +of8NdIYflycxa9MMZwjUWNVSDU4ZujAWKT0Bsh8pv2N/O2A/ypIiwUzljXRPgQHntZb AVw3LQb/yaP2aLSkRDX1uoDwzbTNnifaheWIVSN5FLXFszfCpjoeDnl3nkmu0Svin0GT xsToUnZa2J3mOjlFUkF3eJILBjMtRWC2GKZmHOdon8sHNsg6CC8kOLTNRtx6RToaVqAM kURXO187jDRswd2iE64ufKBM1W4Cg8Ry/tWS8EnFTFjvY2+E1RfwpyaROJDyhJIeq/xN LTQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AgJ3P5TSBGZilokHFX8v5OKRIwn1E+p9CC+Sd10NgMQ=; b=oI9Gnbq8jLRoi4GbzAqCd/ekkpSihnGKZZm8+hrB4Hc7qMuSi84YdtGrB/car0uOIg 6ithpzDIijniW4krYY/+UZMXMg/mZpJ3cjL0GFDqTicLbJ9KNv0t3d274bDGqerAP2c3 sMZQL2kvsMUUtmcpV8JETfzT2Cn0Swq8iRaikbBeYfxJSRDiXvvpeVy6b61DrVX4eUAX uAf6yJd32daGTLDRsTPgTIw/RhCHvzO2nRa9sCRcq//3RvJtTHW/sf7bQTkNw3TuEYx0 ulHRbjArRTk12hYsgBer9KB8L75yJCbOLToIetDap2IqEl+LIKwIE/awWZhOAwram4oM osXw== X-Gm-Message-State: AOAM530+3q6P9NaTqKfx+oz+iSgvXiv0VhVkTACrkxHFYHpW8JTM7HrB FNh9GOKxsCtR0x7LwQigWBRd/jg4AAlQHIMr5STO9g== X-Google-Smtp-Source: ABdhPJw///BFE4BaSY8UnV6aE0C4WBjQc/DC3TSJISHaKAazmCia7ZOh3/BZ8cz1zZ13sXf8TG/iQdUxReSmgKICNfE= X-Received: by 2002:a17:906:fb9b:: with SMTP id lr27mr7997127ejb.175.1607098107080; Fri, 04 Dec 2020 08:08:27 -0800 (PST) MIME-Version: 1.0 References: <20201202052330.474592-1-pasha.tatashin@soleen.com> <20201202052330.474592-6-pasha.tatashin@soleen.com> <20201203091703.GA17338@dhcp22.suse.cz> <20201204084312.GA25569@dhcp22.suse.cz> <20201204085401.GB25569@dhcp22.suse.cz> In-Reply-To: <20201204085401.GB25569@dhcp22.suse.cz> From: Pavel Tatashin Date: Fri, 4 Dec 2020 11:07:51 -0500 Message-ID: Subject: Re: [PATCH 5/6] mm: honor PF_MEMALLOC_NOMOVABLE for all allocations To: Michal Hocko Cc: LKML , linux-mm , Andrew Morton , Vlastimil Babka , David Hildenbrand , Oscar Salvador , Dan Williams , Sasha Levin , Tyler Hicks , Joonsoo Kim , mike.kravetz@oracle.com, Steven Rostedt , Ingo Molnar , Jason Gunthorpe , Peter Zijlstra , Mel Gorman , Matthew Wilcox , David Rientjes , John Hubbard Content-Type: text/plain; charset="UTF-8" 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: On Fri, Dec 4, 2020 at 3:54 AM Michal Hocko wrote: > > On Fri 04-12-20 09:43:13, Michal Hocko wrote: > > On Thu 03-12-20 10:15:41, Pavel Tatashin wrote: > [...] > > > Also, current_gfp_context() is used elsewhere, and in some > > > places removing __GFP_MOVABLE from gfp_mask means that we will need to > > > also change other things. For example [1], in try_to_free_pages() we > > > call current_gfp_context(gfp_mask) which can reduce the maximum zone > > > idx, yet we simply set it to: reclaim_idx = gfp_zone(gfp_mask), not to > > > the newly determined gfp_mask. > > > > Yes and the direct reclaim should honor the movable zone restriction. > > Why should we reclaim ZONE_MOVABLE when the allocation cannot really > > allocate from it? Or have I misunderstood your concern? > > Btw. if we have gfp mask properly filtered for the fast path then we can > remove the additional call to current_gfp_context from the direct > reclaim path. Something for a separate patch. Good point. I am thinking to make a preparation patch at the beginning of the series where we move current_gfp_context() to the fast path, and also address all other cases where this call is not going to be needed anymore, or where the gfp_mask will needed to be set according to what current_gfp_context() returned. Thanks, Pasha