From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 2C6046B0007 for ; Tue, 19 Jun 2018 11:15:02 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id a7-v6so7618467wmg.0 for ; Tue, 19 Jun 2018 08:15:02 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id l40-v6si138546edc.143.2018.06.19.08.15.01 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 19 Jun 2018 08:15:01 -0700 (PDT) Date: Tue, 19 Jun 2018 17:14:25 +0200 From: Michal Hocko Subject: Re: [PATCH 1/2] arm64: avoid alloc memory on offline node Message-ID: <20180619151425.GH13685@dhcp22.suse.cz> References: <16c4db2f-bc70-d0f2-fb38-341d9117ff66@huawei.com> <20180611134303.GC75679@bhelgaas-glaptop.roam.corp.google.com> <20180611145330.GO13364@dhcp22.suse.cz> <87lgbk59gs.fsf@e105922-lin.cambridge.arm.com> <87bmce60y3.fsf@e105922-lin.cambridge.arm.com> <8b715082-14d4-f10b-d2d6-b23be7e4bf7e@huawei.com> <20180619120714.GE13685@dhcp22.suse.cz> <874lhz3pmn.fsf@e105922-lin.cambridge.arm.com> <20180619140818.GA16927@e107981-ln.cambridge.arm.com> <87wouu3jz1.fsf@e105922-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wouu3jz1.fsf@e105922-lin.cambridge.arm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Punit Agrawal Cc: Lorenzo Pieralisi , Xie XiuQi , Hanjun Guo , Bjorn Helgaas , tnowicki@caviumnetworks.com, linux-pci@vger.kernel.org, Catalin Marinas , "Rafael J. Wysocki" , Will Deacon , Linux Kernel Mailing List , Jarkko Sakkinen , linux-mm@kvack.org, wanghuiqiang@huawei.com, Greg Kroah-Hartman , Bjorn Helgaas , Andrew Morton , zhongjiang , linux-arm On Tue 19-06-18 15:54:26, Punit Agrawal wrote: [...] > In terms of $SUBJECT, I wonder if it's worth taking the original patch > as a temporary fix (it'll also be easier to backport) while we work on > fixing these other issues and enabling memoryless nodes. Well, x86 already does that but copying this antipatern is not really nice. So it is good as a quick fix but it would be definitely much better to have a robust fix. Who knows how many other places might hit this. You certainly do not want to add a hack like this all over... -- Michal Hocko SUSE Labs