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=-13.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 9901CC433E1 for ; Fri, 14 Aug 2020 16:50:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 563C12078D for ; Fri, 14 Aug 2020 16:50:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AFvEcPmC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 563C12078D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DC52B6B0006; Fri, 14 Aug 2020 12:50:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D4E656B0007; Fri, 14 Aug 2020 12:50:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C15736B0008; Fri, 14 Aug 2020 12:50:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id A68EC6B0006 for ; Fri, 14 Aug 2020 12:50:13 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5602C812DB6A for ; Fri, 14 Aug 2020 16:50:13 +0000 (UTC) X-FDA: 77149761906.19.seat96_4612b1726ffe Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 1358E1AD1A3 for ; Fri, 14 Aug 2020 16:50:13 +0000 (UTC) X-HE-Tag: seat96_4612b1726ffe X-Filterd-Recvd-Size: 5675 Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 Aug 2020 16:50:12 +0000 (UTC) Received: by mail-pf1-f195.google.com with SMTP id m8so4834203pfh.3 for ; Fri, 14 Aug 2020 09:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=NhtFbl/XT/fNJtXIOkJbd01ZUJG0WSNdtqeIvrQZm5M=; b=AFvEcPmCLr6XEpCa6VqWWD3moPXxkQMbV03UY+L7yPI2N6eVEn+FzCWtH53m7X49Oq pOQ8wauTltihOwF2MwkFreTJEPK3C/AFjRkAzPv3aPGfxNbnFatjwZBbInhqvZGVOMLe m5CHaddGebOKm9LTn99PC4zwVECb7kMrXRnPsEoiQnR7yufZwjjKNidl6aLZfxcm2U5p A+sQlpjWlYwSWsBALV7sTrFGt6ukiCQC6770RyXxxhTOt2itVCq4Mbr8Na3cOVqUiCdI mYcxw34UmGCLYhI/GZHXUl6JYS44kSNc5/5VDECywSv+SnP5DcT1V1TmjSoYILnWhPKM TGQg== 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; bh=NhtFbl/XT/fNJtXIOkJbd01ZUJG0WSNdtqeIvrQZm5M=; b=L4q4NdCs+huIGkHsxujRHAQmj4UJ6wM/o3qrDEZhDFHwQm4a53F75V3su1ZU6Rqrmt hvdMctTSCeFQMPExPAq5GwJ5CMTFGVgRVqTx6TkO89mNXWuYTuVyUimlE8jPggAFXNg6 Ng3wnhGTM+PByMXz4C0y7xaKCGF4wqDT6cnU5fABzXgnmkYuLWHjjHEf6BGEEtGWkry+ mXqgH//2ndRkvWECBXJ5KKQfS8/LVutkMs4rNUyfuyUT/8bgawte81Lh5JrbsQji5dLO FrnKIyO2dUniOUKHvJvodB37YK/Sh1o1ZqUOoRXwt7cEdYD17+B/PFtUVbPFsRM9lsLO 9kXQ== X-Gm-Message-State: AOAM532RzDLlo61PJuKz2ykPP9dHDczRwCzSaipgobM9qmm2yr3hzkM0 V1jeU0sivbOPO0oTXUFz8+U= X-Google-Smtp-Source: ABdhPJz54ssn56mHayR6quMpHG5wxmawgiA9EHX7ihUxI+z8K87Svdcz2Gq/wnolVhHBau/eI148ow== X-Received: by 2002:a63:1523:: with SMTP id v35mr2396760pgl.317.1597423811498; Fri, 14 Aug 2020 09:50:11 -0700 (PDT) Received: from stbirv-lnx-3.igp.broadcom.net ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id s125sm9952636pfb.125.2020.08.14.09.50.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2020 09:50:10 -0700 (PDT) From: Doug Berger To: Andrew Morton Cc: Jason Baron , David Rientjes , "Kirill A. Shutemov" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Doug Berger Subject: [PATCH v2] mm: include CMA pages in lowmem_reserve at boot Date: Fri, 14 Aug 2020 09:49:26 -0700 Message-Id: <1597423766-27849-1-git-send-email-opendmb@gmail.com> X-Mailer: git-send-email 2.7.4 X-Rspamd-Queue-Id: 1358E1AD1A3 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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: The lowmem_reserve arrays provide a means of applying pressure against allocations from lower zones that were targeted at higher zones. Its values are a function of the number of pages managed by higher zones and are assigned by a call to the setup_per_zone_lowmem_reserve() function. The function is initially called at boot time by the function init_per_zone_wmark_min() and may be called later by accesses of the /proc/sys/vm/lowmem_reserve_ratio sysctl file. The function init_per_zone_wmark_min() was moved up from a module_init to a core_initcall to resolve a sequencing issue with khugepaged. Unfortunately this created a sequencing issue with CMA page accounting. The CMA pages are added to the managed page count of a zone when cma_init_reserved_areas() is called at boot also as a core_initcall. This makes it uncertain whether the CMA pages will be added to the managed page counts of their zones before or after the call to init_per_zone_wmark_min() as it becomes dependent on link order. With the current link order the pages are added to the managed count after the lowmem_reserve arrays are initialized at boot. This means the lowmem_reserve values at boot may be lower than the values used later if /proc/sys/vm/lowmem_reserve_ratio is accessed even if the ratio values are unchanged. In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout [ 0.000000] cma: Reserved 256 MiB at 0x0000000030000000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] Normal empty [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff] would result in 0 lowmem_reserve for the DMA zone. This would allow userspace to deplete the DMA zone easily. Funnily enough $ cat /proc/sys/vm/lowmem_reserve_ratio would fix up the situation because it forces setup_per_zone_lowmem_reserve as a side effect. This commit breaks the link order dependency by invoking init_per_zone_wmark_min() as a postcore_initcall so that the CMA pages have the chance to be properly accounted in their zone(s) and allowing the lowmem_reserve arrays to receive consistent values. Fixes: bc22af74f271 ("mm: update min_free_kbytes from khugepaged after core initialization") Signed-off-by: Doug Berger Acked-by: Michal Hocko --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 8b7d0ecf30b1..f3e340ec2b6b 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7887,7 +7887,7 @@ int __meminit init_per_zone_wmark_min(void) return 0; } -core_initcall(init_per_zone_wmark_min) +postcore_initcall(init_per_zone_wmark_min) /* * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so -- 2.7.4