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 D4DB4C433DF for ; Fri, 29 May 2020 09:49:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B054520776 for ; Fri, 29 May 2020 09:49:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590745770; bh=0C6iCaTul0/kwSOJgixdIrP2VzJRsznycAi9fUqICJE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=P/OXMY69nYfltkpVl/BeGMvAMeIqDXWMSxlVNKEtY/nfVUgC0XJ8qsC9N06V/ehvJ 7TF7JlfeH3K+sX6V9DJTAzsinTPq7hdt/Lix2VOf+iC61hbZQoy6g+QakMj+R35HvV KR/zCGp8EPpUrb5+aEsCEm4VzaL0iwDZBvlvKpFw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725914AbgE2JtX (ORCPT ); Fri, 29 May 2020 05:49:23 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:38563 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725681AbgE2JtW (ORCPT ); Fri, 29 May 2020 05:49:22 -0400 Received: by mail-wr1-f65.google.com with SMTP id e1so2804030wrt.5; Fri, 29 May 2020 02:49:20 -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=4SLMrx0MWc8j4vJRn7Kgzb3DUyQWlx2ZLRbxHmKbcbE=; b=Ffo8IQE++6k+frzciH7ED5GMNv607o7tgzOMgs1l+TpeHRJXG3eXOUNr7/LwzY4RkD PgADuitQPfprFo2OdNyXJKZpRT0a+5rWOowb5oFllzkM757hs7ia+jBnhaOgxMG/KBic 3IjxMv+NTvlerppX3wn2Tb8gHduqqxxgkxGmneN97HRbv36JwL4iHDni6NgAfMcM3E+0 dgEeUqtNbuEvWOyuPIZijNvyIAfUnbeGUXBDdq9ayEpy9QgTzb543MXJe27gGYAbb73B 3ULgH6nrR4qTuM56Sa4MCsBHMetJ5uGsloJgkk42ZrJhoWvL/mapbyzSOdJ/evRKTne2 WAWQ== X-Gm-Message-State: AOAM532Olg01nDQb4vFu/oik4+0BT/DJXCM6MLCo6rsp16qubFQ0VlAh OX3qc5dyHJtdbLvO8dUDZ68= X-Google-Smtp-Source: ABdhPJynJWn/appsj5zHjc6kja0kVDlwDRUmuKllOuUorUMxNbkdmaKubkMD/idzdl3klO6z62m4Rg== X-Received: by 2002:adf:f58b:: with SMTP id f11mr7947420wro.155.1590745760055; Fri, 29 May 2020 02:49:20 -0700 (PDT) Received: from localhost (ip-37-188-150-59.eurotel.cz. [37.188.150.59]) by smtp.gmail.com with ESMTPSA id 5sm9907553wmd.19.2020.05.29.02.49.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2020 02:49:18 -0700 (PDT) Date: Fri, 29 May 2020 11:49:10 +0200 From: Michal Hocko To: Chris Down Cc: Yafang Shao , Naresh Kamboju , 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: <20200529094910.GH4406@dhcp22.suse.cz> References: <20200520190906.GA558281@chrisdown.name> <20200521095515.GK6462@dhcp22.suse.cz> <20200521163450.GV6462@dhcp22.suse.cz> <20200528150310.GG27484@dhcp22.suse.cz> <20200528164121.GA839178@chrisdown.name> <20200529015644.GA84588@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200529015644.GA84588@chrisdown.name> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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?). -- Michal Hocko SUSE Labs 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 07D82C433E0 for ; Fri, 29 May 2020 09:49:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C551A2074B for ; Fri, 29 May 2020 09:49:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C551A2074B 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 4AF79800BE; Fri, 29 May 2020 05:49:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 45E8F80010; Fri, 29 May 2020 05:49:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34CD4800BE; Fri, 29 May 2020 05:49:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id 1BF4780010 for ; Fri, 29 May 2020 05:49:22 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C3E2A180AD81D for ; Fri, 29 May 2020 09:49:21 +0000 (UTC) X-FDA: 76869283722.13.tub37_6ecb55d4f0761 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id A36BA18140B60 for ; Fri, 29 May 2020 09:49:21 +0000 (UTC) X-HE-Tag: tub37_6ecb55d4f0761 X-Filterd-Recvd-Size: 5102 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Fri, 29 May 2020 09:49:21 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id s8so2744409wrt.9 for ; Fri, 29 May 2020 02:49:21 -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=4SLMrx0MWc8j4vJRn7Kgzb3DUyQWlx2ZLRbxHmKbcbE=; b=LH8BgFwMALlFZpi3fcH0WD/faw/2gh9bVkYRBnu6aa+3lwDjtv3ZwA37uuOgS9beWU me/Gvg2GmbQ9oM0N3iDVY73DxzpEAdKEpbm8ZlJG//lgPSstaV3wK8+hOCdBEtmHvUvt 6z/kTmNMD9HfIyCo+b8qi9Fslp6dPwkbeR7udcgbKIynWK4hHBMYUZK/AZaZbWIgPHdi HG+DVSCqATXdK83cRTH+GWmKJBFjk4kHMhj8WEdWDkPZP/y9VS1K/4L03QT4TUU3dytS WoygLvz/c7LzycVlGkIpmHrxE9qJlHqL8s5QpSvZqkAHJtVL2tMaf5IjQIIiPdd6VqdE vyvw== X-Gm-Message-State: AOAM533VrvU/zy/PuRrdwp3Mcrs8nbKYE4Uk0OJLLioVjxbacPRVzICr tNSLMQJWy4bIClnVSv8XNe4= X-Google-Smtp-Source: ABdhPJynJWn/appsj5zHjc6kja0kVDlwDRUmuKllOuUorUMxNbkdmaKubkMD/idzdl3klO6z62m4Rg== X-Received: by 2002:adf:f58b:: with SMTP id f11mr7947420wro.155.1590745760055; Fri, 29 May 2020 02:49:20 -0700 (PDT) Received: from localhost (ip-37-188-150-59.eurotel.cz. [37.188.150.59]) by smtp.gmail.com with ESMTPSA id 5sm9907553wmd.19.2020.05.29.02.49.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2020 02:49:18 -0700 (PDT) Date: Fri, 29 May 2020 11:49:10 +0200 From: Michal Hocko To: Chris Down Cc: Yafang Shao , Naresh Kamboju , 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: <20200529094910.GH4406@dhcp22.suse.cz> References: <20200520190906.GA558281@chrisdown.name> <20200521095515.GK6462@dhcp22.suse.cz> <20200521163450.GV6462@dhcp22.suse.cz> <20200528150310.GG27484@dhcp22.suse.cz> <20200528164121.GA839178@chrisdown.name> <20200529015644.GA84588@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200529015644.GA84588@chrisdown.name> X-Rspamd-Queue-Id: A36BA18140B60 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: 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?). -- Michal Hocko SUSE Labs 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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 5BC19C433E0 for ; Fri, 29 May 2020 09:49:29 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 296302074B for ; Fri, 29 May 2020 09:49:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="hc6D9VkH"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="BKa7/cjN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 296302074B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jebdo-0008M4-OR; Fri, 29 May 2020 09:49:28 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jebdn-0008LO-Jx for linux-f2fs-devel@lists.sourceforge.net; Fri, 29 May 2020 09:49:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4SLMrx0MWc8j4vJRn7Kgzb3DUyQWlx2ZLRbxHmKbcbE=; b=hc6D9VkHE9/yS/qshiULvLk/0F fp8i63Xtun8m0Ua2kWPKq6s5NgwK772nHdinepzUpmf5MTjRMGTrgI3Trnn/0lQ/2646Jpq0PRNd2 efEqE4QS5fO4AhskVysb9hEHqxfe++2DYeoLHbzOivGjvlnlTb4CCqlnDRH0qkIABjZk=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4SLMrx0MWc8j4vJRn7Kgzb3DUyQWlx2ZLRbxHmKbcbE=; b=BKa7/cjNRFVPpKgbNmfiu6w8n/ owlQIj1qyaVI4iQlCjyjz4Ls61WpXxievI2hm80pfyWi1K6mPuy2lIosGlYSkYcedi37Icc/Hvccv Kgfe/LeMsgqCehZmJiP6qXFo3vcNAvH0X6sCmil5spb2ztpCM/oBMEYrIzTzckoRqKnc=; Received: from mail-wr1-f68.google.com ([209.85.221.68]) by sfi-mx-4.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.2) id 1jebdm-002YoD-C2 for linux-f2fs-devel@lists.sourceforge.net; Fri, 29 May 2020 09:49:27 +0000 Received: by mail-wr1-f68.google.com with SMTP id x13so2801093wrv.4 for ; Fri, 29 May 2020 02:49:26 -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=4SLMrx0MWc8j4vJRn7Kgzb3DUyQWlx2ZLRbxHmKbcbE=; b=tN3SsiaLED7s5hjbYgv0vsa9e50EU94nDjAK5Ao1pbUmjIrzw41XXwaDDp5ArrAOJL Sl3gPC0ox8VhRoL6/bU3SyY76lcMjkgnl2EhW9YSFmxgWUcLGmtG0NM80uCUPGbVqFLV czXxrJqaZ38XSRNTziwhboBXXL3GCEFbqjAHLg+GbczKq9PMgKd3KmuwzT4wujCWZlzu QjwOYIqTg3SqXIdYkrlOMgm+EU4MnJbUbIkzph0oFfaH8HrLKJUD4oPdFPpCrNcnZPkE LpvorjesGpi4pEPl/WIYIuTpzTQbxbUYAmrvA3jGetwh2jqw++vsIHGlQSMDgGabxZbK Pmlw== X-Gm-Message-State: AOAM53177Da6sP+OAQyme6iGslLRezRqDuiynUEiZhc32om+avsvdGyq y0xIPw/BQ2rBHvutcPlQ8TqvrrX5 X-Google-Smtp-Source: ABdhPJynJWn/appsj5zHjc6kja0kVDlwDRUmuKllOuUorUMxNbkdmaKubkMD/idzdl3klO6z62m4Rg== X-Received: by 2002:adf:f58b:: with SMTP id f11mr7947420wro.155.1590745760055; Fri, 29 May 2020 02:49:20 -0700 (PDT) Received: from localhost (ip-37-188-150-59.eurotel.cz. [37.188.150.59]) by smtp.gmail.com with ESMTPSA id 5sm9907553wmd.19.2020.05.29.02.49.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2020 02:49:18 -0700 (PDT) Date: Fri, 29 May 2020 11:49:10 +0200 From: Michal Hocko To: Chris Down Message-ID: <20200529094910.GH4406@dhcp22.suse.cz> References: <20200520190906.GA558281@chrisdown.name> <20200521095515.GK6462@dhcp22.suse.cz> <20200521163450.GV6462@dhcp22.suse.cz> <20200528150310.GG27484@dhcp22.suse.cz> <20200528164121.GA839178@chrisdown.name> <20200529015644.GA84588@chrisdown.name> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200529015644.GA84588@chrisdown.name> X-Headers-End: 1jebdm-002YoD-C2 Subject: Re: [f2fs-dev] mm: mkfs.ext4 invoked oom-killer on i386 - pagecache_get_page X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lkft-triage@lists.linaro.org, linux-mm , Yafang Shao , Andreas Dilger , Cgroups , Andrea Arcangeli , Anders Roxell , Naresh Kamboju , Hugh Dickins , Matthew Wilcox , Linux-Next Mailing List , linux-ext4 , Arnd Bergmann , linux-block , Jaegeuk Kim , Theodore Ts'o , open list , "Linux F2FS DEV, Mailing List" , Johannes Weiner , Andrew Morton , Roman Gushchin Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net 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?). -- Michal Hocko SUSE Labs _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: mm: mkfs.ext4 invoked oom-killer on i386 - pagecache_get_page Date: Fri, 29 May 2020 11:49:10 +0200 Message-ID: <20200529094910.GH4406@dhcp22.suse.cz> References: <20200520190906.GA558281@chrisdown.name> <20200521095515.GK6462@dhcp22.suse.cz> <20200521163450.GV6462@dhcp22.suse.cz> <20200528150310.GG27484@dhcp22.suse.cz> <20200528164121.GA839178@chrisdown.name> <20200529015644.GA84588@chrisdown.name> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20200529015644.GA84588-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Chris Down Cc: Yafang Shao , Naresh Kamboju , 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 , lkf 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?). -- Michal Hocko SUSE Labs