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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 AE0E0C4361B for ; Tue, 15 Dec 2020 05:22:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 809A42229C for ; Tue, 15 Dec 2020 05:22:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726248AbgLOFWI (ORCPT ); Tue, 15 Dec 2020 00:22:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726212AbgLOFV5 (ORCPT ); Tue, 15 Dec 2020 00:21:57 -0500 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13897C0617A7 for ; Mon, 14 Dec 2020 21:21:17 -0800 (PST) Received: by mail-ed1-x544.google.com with SMTP id dk8so19662357edb.1 for ; Mon, 14 Dec 2020 21:21:17 -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=DtoFrDGyRzomOBINo4k6/LLWjzIuvMntHICBSDufujU=; b=JccyEeDCqJGvzrnf2MTHV8vENXCE6EcEbKHITxFkBO6S45+kn+osTIpTjWRM3JtZzb vPNNdbh5S1JVM6LI9b4DAi1HSURysZF24us8TaPcZPi4KFLMvmggU5+OyCQKe8XTQsAc 33BL/38GifT8ctNK9/YkhL2cd4BcyB0koGRZHwFnm8E6zJWZ2ODFlYlUqZxwvLxgedwT PJKUgrfIFKkNGGBF7KS7nYRoNQznH13b87lhRhv3fJymmBExXI74BqviWJOlMg02DfSB mqjs+rdiet8J7N3eIxlNMVG7tLXZZIZGnLNjjC7+UaB3cYlooKmKrAG1qCFKu2x4n5U+ Nwvg== 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=DtoFrDGyRzomOBINo4k6/LLWjzIuvMntHICBSDufujU=; b=Is7NUx3gW72G4LT19WhdtMtbz+4IshDsi27QbAJ8ZvLWlY0ga1UE68q61muD/a/Byj ha1QfXqD3+bmJVEVSR+SVl22SHV16zyPV1ehFlzCxXpk76MowYfoDTbGpZFZX4+Lwkxo lZe+1W2IFw7SsETCD2rhvuNqmgw8iTXimc2Dd6FDFx61gkqDT7WGvl9uYxRAmnV8VYtR fVFED8qiJ+VDPtWmZhXTYR7lvxjzsvqEH+oBvms7GTXNO66dcCg9cLfTgel0bWoWpGw8 NvklEm3334kYRBldCcm/XvxkLnj7Ho6zYuc5lslMf4cOPjcA++s8obGrI6qWiZVAtiv8 O8WQ== X-Gm-Message-State: AOAM531kqgahZGiNdRGZ9luLoW1nBPr7xkd+IpUkhgxzTl+yejHBRSYd pZb04pJoarbqyG+vPKdvw1dUIxyoZq1SNq44+AIiUg== X-Google-Smtp-Source: ABdhPJymYnD0yKSOBXxwE4d162v7Rhh7achqxetqFLI95KAw3f9XowfmwGq2H2/sTiKf/Lsn8U2gqBc4k8RGnx9uCRI= X-Received: by 2002:a05:6402:95c:: with SMTP id h28mr853886edz.26.1608009675762; Mon, 14 Dec 2020 21:21:15 -0800 (PST) MIME-Version: 1.0 References: <20201211202140.396852-1-pasha.tatashin@soleen.com> <20201211202140.396852-4-pasha.tatashin@soleen.com> <20201214140912.GE32193@dhcp22.suse.cz> In-Reply-To: <20201214140912.GE32193@dhcp22.suse.cz> From: Pavel Tatashin Date: Tue, 15 Dec 2020 00:20:39 -0500 Message-ID: Subject: Re: [PATCH v3 3/6] mm: apply per-task gfp constraints in fast path 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 , Linux Doc Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Ack to this. Thank you. > > But I do not really understand this. All allocation contexts should have > a proper gfp mask so why do we have to call current_gfp_context here? > In fact moving the current_gfp_context in the allocator path should have > made all this games unnecessary. Memcg reclaim path might need some > careful check because gfp mask is used more creative there but the > general reclaim paths should be ok. > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > Again, why do we need this when the gfp_mask > > }; > > -- Hi Michal, Beside from __alloc_pages_nodemask(), the current_gfp_context() is called from the following six functions: try_to_free_pages() try_to_free_mem_cgroup_pages() __node_reclaim() __need_fs_reclaim() alloc_contig_range() pcpu_alloc() As I understand, the idea is that because the allocator now honors gfp_context values for all paths, the call can be removed from some of the above functions. I think you are correct. But, at least from a quick glance, this is not obvious, and is not the case for all of the above functions. For example: alloc_contig_range() __alloc_contig_migrate_range isolate_migratepages_range isolate_migratepages_block /* * Only allow to migrate anonymous pages in GFP_NOFS context * because those do not depend on fs locks. */ if (!(cc->gfp_mask & __GFP_FS) && page_mapping(page)) goto isolate_fail; If we remove current_gfp_context() from alloc_contig_range(), the cc->gfp_mask will not be updated with proper __GFP_FS flag. I have studied some other paths, and they are also convoluted. Therefore, I am worried about performing this optimization in this series. 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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 91D2DC4361B for ; Tue, 15 Dec 2020 05:21:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 260022228A for ; Tue, 15 Dec 2020 05:21:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 260022228A 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 3E4938D0008; Tue, 15 Dec 2020 00:21:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A08D8D0005; Tue, 15 Dec 2020 00:21:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2816A8D0008; Tue, 15 Dec 2020 00:21:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id 0821A8D0005 for ; Tue, 15 Dec 2020 00:21:18 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B24B68249980 for ; Tue, 15 Dec 2020 05:21:17 +0000 (UTC) X-FDA: 77594368194.16.fruit12_4d0b82827420 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 9377D100E6903 for ; Tue, 15 Dec 2020 05:21:17 +0000 (UTC) X-HE-Tag: fruit12_4d0b82827420 X-Filterd-Recvd-Size: 5123 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Dec 2020 05:21:17 +0000 (UTC) Received: by mail-ed1-f68.google.com with SMTP id q16so19614029edv.10 for ; Mon, 14 Dec 2020 21:21:16 -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=DtoFrDGyRzomOBINo4k6/LLWjzIuvMntHICBSDufujU=; b=JccyEeDCqJGvzrnf2MTHV8vENXCE6EcEbKHITxFkBO6S45+kn+osTIpTjWRM3JtZzb vPNNdbh5S1JVM6LI9b4DAi1HSURysZF24us8TaPcZPi4KFLMvmggU5+OyCQKe8XTQsAc 33BL/38GifT8ctNK9/YkhL2cd4BcyB0koGRZHwFnm8E6zJWZ2ODFlYlUqZxwvLxgedwT PJKUgrfIFKkNGGBF7KS7nYRoNQznH13b87lhRhv3fJymmBExXI74BqviWJOlMg02DfSB mqjs+rdiet8J7N3eIxlNMVG7tLXZZIZGnLNjjC7+UaB3cYlooKmKrAG1qCFKu2x4n5U+ Nwvg== 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=DtoFrDGyRzomOBINo4k6/LLWjzIuvMntHICBSDufujU=; b=ZhKXR6wnyXaYLWDao34y3+kUzusPkBH6Mp/NuOJKiuq9nI9fVVv53CPsePa1P+z/Jt wAM+ZlrPn1x40OaM63M8286V+MrJwE4CCIazqEc1NHxxja9re2trEA4QG5G89lJeivcz IZmHYRGQyVmDmsycaJmJ6Tz61RrweYs/U3XEKWKP4Qj/CBwk3NmMYXubADCCstpHsgyK gWoZEEvrIp7+y4PP2CcvMc5Z90/zpw8bES9tuBiDp9OOwtmDcXBSZH4DUoKyUTkOzl3C sC0kNItbi4vzjIdVJxrcZlGREiQatG1KOaOgsfEPewUoaUFH3tjm/iIRZ0XopCD5DDuK 1STA== X-Gm-Message-State: AOAM530zqYwhk8On9/TlhK6QNIW+FpQdSGXVTQT8+Cvn69JsfR9dfH9C oqTQHWqWlT9dTGqHtBAKXcmosR8tdgIzy29qOeqpNw== X-Google-Smtp-Source: ABdhPJymYnD0yKSOBXxwE4d162v7Rhh7achqxetqFLI95KAw3f9XowfmwGq2H2/sTiKf/Lsn8U2gqBc4k8RGnx9uCRI= X-Received: by 2002:a05:6402:95c:: with SMTP id h28mr853886edz.26.1608009675762; Mon, 14 Dec 2020 21:21:15 -0800 (PST) MIME-Version: 1.0 References: <20201211202140.396852-1-pasha.tatashin@soleen.com> <20201211202140.396852-4-pasha.tatashin@soleen.com> <20201214140912.GE32193@dhcp22.suse.cz> In-Reply-To: <20201214140912.GE32193@dhcp22.suse.cz> From: Pavel Tatashin Date: Tue, 15 Dec 2020 00:20:39 -0500 Message-ID: Subject: Re: [PATCH v3 3/6] mm: apply per-task gfp constraints in fast path 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 , Linux Doc Mailing List 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: > Ack to this. Thank you. > > But I do not really understand this. All allocation contexts should have > a proper gfp mask so why do we have to call current_gfp_context here? > In fact moving the current_gfp_context in the allocator path should have > made all this games unnecessary. Memcg reclaim path might need some > careful check because gfp mask is used more creative there but the > general reclaim paths should be ok. > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > Again, why do we need this when the gfp_mask > > }; > > -- Hi Michal, Beside from __alloc_pages_nodemask(), the current_gfp_context() is called from the following six functions: try_to_free_pages() try_to_free_mem_cgroup_pages() __node_reclaim() __need_fs_reclaim() alloc_contig_range() pcpu_alloc() As I understand, the idea is that because the allocator now honors gfp_context values for all paths, the call can be removed from some of the above functions. I think you are correct. But, at least from a quick glance, this is not obvious, and is not the case for all of the above functions. For example: alloc_contig_range() __alloc_contig_migrate_range isolate_migratepages_range isolate_migratepages_block /* * Only allow to migrate anonymous pages in GFP_NOFS context * because those do not depend on fs locks. */ if (!(cc->gfp_mask & __GFP_FS) && page_mapping(page)) goto isolate_fail; If we remove current_gfp_context() from alloc_contig_range(), the cc->gfp_mask will not be updated with proper __GFP_FS flag. I have studied some other paths, and they are also convoluted. Therefore, I am worried about performing this optimization in this series.