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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 E2D20C432C1 for ; Wed, 25 Sep 2019 06:36:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A1A8A21D7E for ; Wed, 25 Sep 2019 06:36:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A1A8A21D7E 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 5337E6B0275; Wed, 25 Sep 2019 02:36:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E4126B0276; Wed, 25 Sep 2019 02:36:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 423386B0277; Wed, 25 Sep 2019 02:36:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id 216E86B0275 for ; Wed, 25 Sep 2019 02:36:54 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id C69AE813D for ; Wed, 25 Sep 2019 06:36:53 +0000 (UTC) X-FDA: 75972485106.19.nut08_3c2a39f156950 X-HE-Tag: nut08_3c2a39f156950 X-Filterd-Recvd-Size: 2790 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Sep 2019 06:36:53 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8B53AAE55; Wed, 25 Sep 2019 06:36:49 +0000 (UTC) Date: Wed, 25 Sep 2019 08:36:48 +0200 From: Michal Hocko To: Linus Torvalds Cc: Andrew Morton , David Rientjes , Vlastimil Babka , Andrea Arcangeli , mm-commits@vger.kernel.org, Linux-MM Subject: Re: incoming Message-ID: <20190925063648.GD23050@dhcp22.suse.cz> References: <20190923153142.a7a7590798baebd3e1531083@linux-foundation.org> <20190923213153.62d56ab13a655aa7e2a583af@linux-foundation.org> <20190924074843.GC23050@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 Tue 24-09-19 08:34:20, Linus Torvalds wrote: > On Tue, Sep 24, 2019 at 12:48 AM Michal Hocko wrote: > > > > The patch proposed by David is really non trivial wrt. potential side > > effects. > > The thing is, that's not an argument when we know that the current > state is garbage and has a lot of these non-trivial side effects that > are bad. > > So the patch by David _fixes_ a non-trivial bad side effect. > > You can't then say "there may be other non-trivial side effects that I > don't even know about" as an argument for saying it's bad. David at > least has numbers and an argument for his patch. All I am saying is that I am not able to wrap my head around this patch to provide a competent Ack. I also believe that the fix is targetting a wrong layer of the problem as explained in my review feedback. Appart from reclaim/compaction interaction mentioned by Vlastimil, it seems that it is an overly eager fallback to a remote node in the fast path that is causing a large part of the problem as well. Kcompactd is not eager enough to keep high order allocations ready for the fast path. This is not specific to THP we have many other high order allocations which are going to follow the same pattern, likely not visible in any counters but still having performance implications. Let's discuss technical details in the respective email thread -- Michal Hocko SUSE Labs