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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 643BBC388F3 for ; Sat, 28 Sep 2019 20:59:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0BBCC208E4 for ; Sat, 28 Sep 2019 20:59:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="KRjbob1t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BBCC208E4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 435CC6B0003; Sat, 28 Sep 2019 16:59:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E6446B0005; Sat, 28 Sep 2019 16:59:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FCEC6B0006; Sat, 28 Sep 2019 16:59:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0108.hostedemail.com [216.40.44.108]) by kanga.kvack.org (Postfix) with ESMTP id 0E8116B0003 for ; Sat, 28 Sep 2019 16:59:48 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 77B32180AD803 for ; Sat, 28 Sep 2019 20:59:47 +0000 (UTC) X-FDA: 75985546014.11.straw73_384453b954f46 X-HE-Tag: straw73_384453b954f46 X-Filterd-Recvd-Size: 6601 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Sat, 28 Sep 2019 20:59:46 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id x80so4328517lff.3 for ; Sat, 28 Sep 2019 13:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nA9XhvmDPP8zs4JjFJOeuslROAGPKec0VWKiDgsMsAo=; b=KRjbob1tCwjO/4jj3ojiuB847HVXl9G3M3ASy8896FQecUQKkH8RBaQGBAfLo10wgC 5Wtk1CVZ9RRM0oi/PQuiyCxKBXmdArn14By6S/8TM9oV+tPdagEWeiX+DNez5JG7Q5BM WYxuQ/5vFBl/OQqgpeNL/iaJDj9FOMM3O4ffY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nA9XhvmDPP8zs4JjFJOeuslROAGPKec0VWKiDgsMsAo=; b=NSqhKcIq19fEArnGKV51mWpP8rRmebFTuwD7r2F6Hs2VttxfKqADVJ0Cikv6RMDa6/ 0HXsgpDa5PwflR1DIlh4qPdA/PRSWDlYgOnX8YzJz+YkzeVRNuazUxT6I5Rfmac7HkUU bvBFWyiXYSmGdryoIKKEqigHH98jxGUqRJO/wVB1m9cTvvK+o83WbFKurixLlaV+KbYC rHoZc6uWxxAEAJvycTMlRzj4ZRn3YOh7RaQ/irapj8T1QPp0mqAaT53Sz72xLVrtf3Ks eKowDRLVQl1XI9cB8By5Gy0lGIUSfzrL36OTjQ/hHPHk1z79L226jN57ReV6ca+dR48K q/PA== X-Gm-Message-State: APjAAAWsZd5ygHxbTuIUS2FlUz/TfxZFY/5wR5+HNhOVIakuJkF9z5OR Ozxzre7Ez954IlNzL+gYhGWswVEXfnY= X-Google-Smtp-Source: APXvYqzkG1muPnpDGx7DzLXoN2Zk63SfBo+7rTMtcJdWiQYHIA8DOUayPQYpUylz6Ia7MYYifd4ddQ== X-Received: by 2002:a19:f711:: with SMTP id z17mr6743785lfe.58.1569704384044; Sat, 28 Sep 2019 13:59:44 -0700 (PDT) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com. [209.85.167.50]) by smtp.gmail.com with ESMTPSA id y3sm1520353lji.53.2019.09.28.13.59.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Sep 2019 13:59:42 -0700 (PDT) Received: by mail-lf1-f50.google.com with SMTP id r134so4284309lff.12 for ; Sat, 28 Sep 2019 13:59:42 -0700 (PDT) X-Received: by 2002:a19:7d55:: with SMTP id y82mr6858954lfc.106.1569704382232; Sat, 28 Sep 2019 13:59:42 -0700 (PDT) MIME-Version: 1.0 References: <20190904205522.GA9871@redhat.com> <20190909193020.GD2063@dhcp22.suse.cz> <20190925070817.GH23050@dhcp22.suse.cz> <20190927074803.GB26848@dhcp22.suse.cz> In-Reply-To: <20190927074803.GB26848@dhcp22.suse.cz> From: Linus Torvalds Date: Sat, 28 Sep 2019 13:59:26 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch for-5.3 0/4] revert immediate fallback to remote hugepages To: Michal Hocko Cc: David Rientjes , Andrea Arcangeli , Andrew Morton , Mel Gorman , Vlastimil Babka , "Kirill A. Shutemov" , Linux Kernel Mailing List , Linux-MM Content-Type: text/plain; charset="UTF-8" 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, Sep 27, 2019 at 12:48 AM Michal Hocko wrote: > > - page = get_page_from_freelist(gfp_mask, order, alloc_flags, ac); > + if (!order) > + page = get_page_from_freelist(gfp_mask, order, alloc_flags, ac); > if (page) > goto got_pg; > > The whole point of handling this in the page allocator directly is to > have a unified solutions rather than have each specific caller invent > its own way to achieve higher locality. The above just looks hacky. Why would order-0 be special? It really is hugepages that are special - small orders don't generally need a lot of compaction. and this secondary get_page_from_freelist() is not primarily about compaction, it's about relaxing some of the other constraints, and the actual alloc_flags have changed from the initial ones. I really think that you're missing the big picture. We want node locality, and we want big pages, but those "we want" simply shouldn't be as black-and-white as they sometimes are today. In fact, the whole black-and-white thing is completely crazy for anything but some test-load. I will just do the reverts and apply David's two patches on top. We now have the time to actually test the behavior, and we're not just before a release. The thing is, David has numbers, and the patches make _sense_. There's a description of what they do, there are comments, but the *code* makes sense too. Much more sense than the above kind of insane hack. David's patches literally do two things: - [3/4] just admit that the allocation failed when you're trying to allocate a huge-page and compaction wasn't successful - [4/4] when that huge-page allocation failed, retry on another node when appropriate That's _literally_ what David's two patches do. The above is purely the English translation of the patches. And I claim that the English translation also ends up being _sensible_. I go look at those two statements, and my reaction "yeah, that makes sense". So there were numbers, there was "this is sensible", and there were no indications that those sensible choices would actually be problematic. Nobody has actually argued against the patches making sense. Nobody has even argued that the patches would be wrong. The _only_ argument against them were literally "what if this changes something subtle", together with patches like the above that do _not_ make sense either on a big picture level or even locally on a small level. The reason I didn't apply those patches for 5.3 was that they came in very late, and there were horrendous numbers for the 5.2 behavior that caused those two big reverts. But the patches made sense back then, the timing for them just didn't. I was hoping this would just get done in the mm tree, but clearly it isn't, and I'll just do my own mm branch and merge the patches that way. Linus