Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1172750ybg; Thu, 11 Jun 2020 02:56:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwyoCUmLuJDvILoxuk+mU2L+7lXVlbyCrmbjMGnhqXA9rPkrKisPvgS2agFvVB/rtzJ57M X-Received: by 2002:a17:906:7c58:: with SMTP id g24mr8021077ejp.205.1591869410859; Thu, 11 Jun 2020 02:56:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591869410; cv=none; d=google.com; s=arc-20160816; b=e5R/5Fy+3HWi7w8eM7KvSCAHFNnM5uqQN1Z/mjuGzvpfc8gZVz4W3HMw02Ve0eb89h vvGMUr8/Q8d9RyKp7pbg1PX9LYrXJRyWdcGcC80pG1yi1fWJoAugLw5+igdGaEdwTDGn AQxzcYDO7o+AJXaqz+DWXt3ptFBP3qq96zFL1TXc37rAFfHYds7f7MzqtnaqiCT/TLrQ wcaNUjgjoU+8fznO9fvVKD5U3+o3eRlLdHMEtxBnTjTtckg8qhU+NcgJ+MqXDWzUkpMx xScajU+puhNrUhRQsZBwCLDdf9fgBPT3E7Mi5H4+Nd6UkRstTvUyw/F6w6XgFtEP0rfa nOIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=OGc4Jynhv8J9+LXwEVD2pmhTRYA7A0SBRA8Y9bWfwBM=; b=rvKcJQdrCj5I7zV2viUW+rPiyqj11CIwtkZrKqvVYh42dpNXiP+AVvXnd5oCyMqb/t kHirZVpLkuVrnNK+MK9NrcsVJ/6wJGyO6rGGnkOkM3h/e17+jBorTCuDDLGbpy9c9CbO mphumK7tzwqNLEl0LPvx56nPuRB/1J8DYqPi21RG1Y+/z80WwFy6ugSuRg0z3qaLdZL9 Qs0kmJlpizwh8lmbq3fKWdmqMjulRIUMLIDETyCua2X1gAtV0VMJsZalM6iZI8Y062Vx CnFSr4mEeRfJnuVLTZSDekpU36Lq1KE6tzGWJIVwg4UvK61EEuXprwlKap5/yDr8FoaJ TX9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k25si509205eja.712.2020.06.11.02.56.20; Thu, 11 Jun 2020 02:56:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726980AbgFKJzp (ORCPT + 99 others); Thu, 11 Jun 2020 05:55:45 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:33737 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726783AbgFKJzT (ORCPT ); Thu, 11 Jun 2020 05:55:19 -0400 Received: by mail-wm1-f67.google.com with SMTP id j198so6574348wmj.0; Thu, 11 Jun 2020 02:55:17 -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=OGc4Jynhv8J9+LXwEVD2pmhTRYA7A0SBRA8Y9bWfwBM=; b=ZP3WT+PqgLjTcOB43l6GxF4o9GVmkvGG8l8sH87x0bHL7XqW1KaHyZDmXKTjJKOzkt RMgvMWpExF98C4c5Y8zco5vLKDG7hWRa43rDJfaSezsHoqaU+WlrqodiEafdyOR6DLBQ sVAhvx5jJLoHj705kpT+10r+i2FjIpJr8PQg+MUeEUNoTiXzrXv0eurO1JGi1H1SIPOZ S/KzhrJBCblA+SH0Gx9hzDttKjs8TI+oOrIpJt1f1hPWRjpYSRFdWMjxC2GYJ1vt1jOJ t2JOGG6A6SmkoGwePy6IL/YHQJu+TjWJQs041ML6lujAcOHokviij9GvmZXEDyLTidDh gLrA== X-Gm-Message-State: AOAM530ngMhb6vfGTQmJl/t9EPNN5CQTYVgAf7hkzc9JAKRH3GtCAfhI VHBihFejIgcUSJAK6Xm9qRg= X-Received: by 2002:a7b:c18a:: with SMTP id y10mr7719246wmi.73.1591869316876; Thu, 11 Jun 2020 02:55:16 -0700 (PDT) Received: from localhost (ip-37-188-174-201.eurotel.cz. [37.188.174.201]) by smtp.gmail.com with ESMTPSA id 67sm4301281wrk.49.2020.06.11.02.55.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2020 02:55:15 -0700 (PDT) Date: Thu, 11 Jun 2020 11:55:14 +0200 From: Michal Hocko To: Chris Down , Naresh Kamboju Cc: Yafang Shao , Anders Roxell , "Linux F2FS DEV, Mailing List" , linux-ext4 , linux-block , Andrew Morton , open list , Linux-Next Mailing List , linux-mm , Arnd Bergmann , Andreas Dilger , Jaegeuk Kim , Theodore Ts'o , Chao Yu , Hugh Dickins , Andrea Arcangeli , Matthew Wilcox , Chao Yu , lkft-triage@lists.linaro.org, Johannes Weiner , Roman Gushchin , Cgroups Subject: Re: mm: mkfs.ext4 invoked oom-killer on i386 - pagecache_get_page Message-ID: <20200611095514.GD20450@dhcp22.suse.cz> References: <20200521095515.GK6462@dhcp22.suse.cz> <20200521163450.GV6462@dhcp22.suse.cz> <20200528150310.GG27484@dhcp22.suse.cz> <20200528164121.GA839178@chrisdown.name> <20200529015644.GA84588@chrisdown.name> <20200529094910.GH4406@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200529094910.GH4406@dhcp22.suse.cz> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri 29-05-20 11:49:20, Michal Hocko wrote: > On Fri 29-05-20 02:56:44, Chris Down wrote: > > Yafang Shao writes: > > > Look at this patch[1] carefully you will find that it introduces the > > > same issue that I tried to fix in another patch [2]. Even more sad is > > > these two patches are in the same patchset. Although this issue isn't > > > related with the issue found by Naresh, we have to ask ourselves why > > > we always make the same mistake ? > > > One possible answer is that we always forget the lifecyle of > > > memory.emin before we read it. memory.emin doesn't have the same > > > lifecycle with the memcg, while it really has the same lifecyle with > > > the reclaimer. IOW, once a reclaimer begins the protetion value should > > > be set to 0, and after we traversal the memcg tree we calculate a > > > protection value for this reclaimer, finnaly it disapears after the > > > reclaimer stops. That is why I highly suggest to add an new protection > > > member in scan_control before. > > > > I agree with you that the e{min,low} lifecycle is confusing for everyone -- > > the only thing I've not seen confirmation of is any confirmed correlation > > with the i386 oom killer issue. If you've validated that, I'd like to see > > the data :-) > > Agreed. Even if e{low,min} might still have some rough edges I am > completely puzzled how we could end up oom if none of the protection > path triggers which the additional debugging should confirm. Maybe my > debugging patch is incomplete or used incorrectly (maybe it would be > esier to use printk rather than trace_printk?). It would be really great if we could move forward. While the fix (which has been dropped from mmotm) is not super urgent I would really like to understand how it could hit the observed behavior. Can we double check that the debugging patch really doesn't trigger (e.g. s@trace_printk@printk in the first step)? I have checked it again but do not see any potential code path which would be affected by the patch yet not trigger any output. But another pair of eyes would be really great. -- Michal Hocko SUSE Labs