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=-1.0 required=3.0 tests=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 0B393C10F27 for ; Tue, 10 Mar 2020 09:16:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CCED82467F for ; Tue, 10 Mar 2020 09:16:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CCED82467F 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 5ED2D6B0005; Tue, 10 Mar 2020 05:16:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 59DEA6B0006; Tue, 10 Mar 2020 05:16:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B4686B0007; Tue, 10 Mar 2020 05:16:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id 333286B0005 for ; Tue, 10 Mar 2020 05:16:40 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0CEFB4DD3 for ; Tue, 10 Mar 2020 09:16:40 +0000 (UTC) X-FDA: 76578897318.04.coat33_745d0e88edb3c X-HE-Tag: coat33_745d0e88edb3c X-Filterd-Recvd-Size: 4621 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Mar 2020 09:16:39 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id 6so14805044wre.4 for ; Tue, 10 Mar 2020 02:16:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=fz3n4QEA4mMM+MBbJX+cMGlCMEaVSqf4LwkZvYcSZEw=; b=FSQ1V5LvKswyM7fm16I7EKSLQeba8k+8GaXZMlzBjftJKbV7wtzfNAipY+oDW1IaUa PyBxMzsnbws3umiYcwM4tMKnEck4KlWb6BnLw6WUHC8YiOfjcg8zW34rjUZRH1NO9SwB WrbTNVA2DEopea7W8g8HRejXO+SrJfxBmWJ6N5qyVsW2qANKnF5vgqTHW98qt+5E+kAw WsWh3wT50AxLvOXrjfk5bfkQyZABvVXv01BiOlZWfa3dJEqYzqdQ3E/J/pwpx8ExUaHl YVJeP/mvxlHPycAl1gbGg9IYoTcDsTJE5NGdJ1jIAo/IlLHlQ1gOOpgcSHG8UX5rO9Vi 5lyg== X-Gm-Message-State: ANhLgQ3BP+ReXeVvOQinFFXaR6VIIs/joo/NoQu3rHsKn04PI6OyMoOq RbOEfEfm8qKCmpMlxj9xNzo= X-Google-Smtp-Source: ADFU+vszMTJIkVmx1ZNqIN9KzQ8vaeAT6TaRYkPc1p0pHRH6nNgZB8aQkPvG80FiR8Kt9mo3LxxChg== X-Received: by 2002:adf:92c2:: with SMTP id 60mr9876964wrn.177.1583831798497; Tue, 10 Mar 2020 02:16:38 -0700 (PDT) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id j14sm65506521wrn.32.2020.03.10.02.16.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2020 02:16:37 -0700 (PDT) Date: Tue, 10 Mar 2020 10:16:37 +0100 From: Michal Hocko To: Arnd Bergmann Cc: Russell King - ARM Linux admin , Nishanth Menon , Santosh Shilimkar , Tero Kristo , Linux ARM , Rik van Riel , Catalin Marinas , Santosh Shilimkar , Dave Chinner , Linux Kernel Mailing List , Linux-MM , Yafang Shao , Al Viro , Johannes Weiner , linux-fsdevel , kernel-team@fb.com, Kishon Vijay Abraham I , Linus Torvalds , Andrew Morton , Roman Gushchin Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Message-ID: <20200310091637.GC8447@dhcp22.suse.cz> References: <671b05bc-7237-7422-3ece-f1a4a3652c92@oracle.com> <7c4c1459-60d5-24c8-6eb9-da299ead99ea@oracle.com> <20200306203439.peytghdqragjfhdx@kahuna> <20200308141923.GI25745@shell.armlinux.org.uk> <20200309140439.GL25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: I am worried this went quite tangent to the original patch under discussion here, but let me clarify at least one point. On Mon 09-03-20 16:04:54, Arnd Bergmann wrote: > On Mon, Mar 9, 2020 at 3:05 PM Russell King - ARM Linux admin [...] > > What happened to requests for memory from highmem being able to be > > sourced from lowmem if highmem wasn't available? That used to be > > standard kernel behaviour. > > AFAICT this is how it's supposed to work, but for some reason it > doesn't always. I don't know the details, but have heard of recent > complaints about it. I don't think it's the actual get_free_pages > failing, but rather some heuristic looking at the number of free pages. This is indeed the case. There are low memory reserves which are not allowed for requests which can be satisfied from higher zones. This is the case for many many years. Just have a look at lowmem_reserve and their usage in __zone_watermark_ok. The layout of the reserves can be configured by /proc/sys/vm/lowmem_reserve_ratio. HTH -- Michal Hocko SUSE Labs