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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 E4022C10F27 for ; Tue, 10 Mar 2020 09:16:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BE331208E4 for ; Tue, 10 Mar 2020 09:16:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583831803; bh=ifu+suw8ibvQBfvdnxiPwN/3r4UIT2U+05cCsS+z0VE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=vgCpvtHPmaqFInVlI4EvWWrjZ/e8QxXSY+nB6/so6dkYu34mBTx3PaFCMvTMoGHF6 db0XK0OEhy0+qIsc9LYHHbYQGlbsCDWjFv5WkRqlLX3GP4Y6e6S1s2a9gQFtNqQ7Qq f6FZwPsOHwCMScfDqp0e0Rau3x6XM4JPC1Jh+Nt8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726558AbgCJJQm (ORCPT ); Tue, 10 Mar 2020 05:16:42 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:40812 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726258AbgCJJQm (ORCPT ); Tue, 10 Mar 2020 05:16:42 -0400 Received: by mail-wr1-f67.google.com with SMTP id p2so13995748wrw.7; 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=EBXKq4nxdeL99uimUiCAa5Xl5Xc4upafB0sj6Esq6i//ChMnp9K3N7evpVDOeqJsE7 89lp2Ybs5CJ2dnFjQd5zSd0uuI4VIgmoEb4H83sT9heUyaufAmHZUkcMDv5T1+1gD+Ln HFbTBydYQNjtzh7gVPMm2hGucEsypZfnp0+uZRVcpiL5A7U7yLqIQvBtYfOYMB8hp9+R Fr/Qgu1aLl0gY8Xpzi6m47RijqVdFdn6StQqBXsQVHIMyqXHzlebU5KRBPis0Be4PQHM PdwldUhTJ0fsuP4qFqpXLjRZ+IIL0tz4ndi83SYICqCTjF2uHRfF863A8OtoPdEEOmYn YgrQ== X-Gm-Message-State: ANhLgQ2kYBj7mBmUf80iWIaWLxtyPn0aMVxn5NjcMgk0n4//nmtwv0BK luYf5UNTl2OhgYDi3YO6o3E= 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: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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