Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Andrew Morton <akpm@linux-foundation.org>,
        kernel test robot <oliver.sang@intel.com>
Cc:     Georgi Djakov <georgi.djakov@linaro.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>, lkp@lists.01.org,
        lkp@intel.com
References: <20210729014019.GA22801@xsang-OptiPlex-9020>
 <20210729114611.13ff7c1c43c883bd039dab40@linux-foundation.org>
From:   Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [mm/page_owner] 866b485262: invoked_oom-killer:gfp_mask=0x
Message-ID: <d0c1717f-a3e1-a9d4-44b2-2452134ad5e5@suse.cz>
Date:   Fri, 30 Jul 2021 10:31:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <20210729114611.13ff7c1c43c883bd039dab40@linux-foundation.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 7/29/21 8:46 PM, Andrew Morton wrote:
> On Thu, 29 Jul 2021 09:40:19 +0800 kernel test robot <oliver.sang@intel.com> wrote:
> 
>> 
>> 
>> Greeting,
>> 
>> FYI, we noticed the following commit (built with gcc-9):
>> 
>> commit: 866b485262173a2b873386162b2ddcfbcb542b4a ("mm/page_owner: record the timestamp of all pages during free")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> I don't see how this can happen unless it's a side-effect of making
> struct page_owner 8 bytes larger.

It's possible. Seems to be a 32bit highmem kernel, allocation that fails is
GFP_USER and the page_owner (part of page_ext) has to be in lowmem, even for
highmem pages, and there's not an insignificant amount of it:

[   16.228923][    T0] allocated 178298840 bytes of page_ext

Seems to be one of the cases where contemporary kernel features are not always
suitable for 32bit kernels (especially with large memory). The highmem is 16GB.
If it was smaller, it would be actually better.

> Does setting
> /proc/sys/vm/oom_dump_tasks tell us more?
>