Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1936800ybp; Wed, 9 Oct 2019 23:16:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqxMIjgNoYvxGbr9CJ8Hufw6mskqlE45e8gdNeFb/AZ1qCrLcd5rwQWGHOI1pg08duAgHJR5 X-Received: by 2002:aa7:cb58:: with SMTP id w24mr6561197edt.158.1570688175845; Wed, 09 Oct 2019 23:16:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570688175; cv=none; d=google.com; s=arc-20160816; b=bh+hcT2LZVGW0trFvp0vhIX9wa/Hoo/sQKLhg1ogyZeUc1Z+2W8Xs07G2JmmQSwi3u OMLaGdHutOrY6fKZR1bavt4slFHTJEQxJeMxKB0H7bLWGhaFpEh/Pjr5xqT4aUOHP9BH hrOqsPj0mwY2qfwvpmEMh2J62Knio+ze06n+CAHmLZcwwolEDhnYjNCUSzt7s9xQtPGb FdKN51YYDAOFy/6nlswGupS7HNnmFuecNN1jjaztYujyNObrBAGehbXQjwB+Gv37nv0H XgTvbo/a7sBCbApbtJ6NpzaCyZCKYp4EmaBPfFAxEzg3HdWlYFLsPyZ207XlP0pUNgqr EjNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :dkim-signature; bh=lWnf3Tivr1DYjpGENqZP4N4/wqKMYNGBsXgFS6zTKa4=; b=LqYb991d32pkS21Sq9n8TBPflqebWqtlLtG9bi1Z8j9KSnHxN/ztz2pW45nC9khX7N qCImgxxU8D400wM4CjmforOmACcYzf+DrImM5ga49Ybf/qSsKNo/zQlNQ5cjjDiG+TkW F5YRZUBkMXmXMW/1aEewVOmMsSUYdvPSfXfthnUk/Zeep0GAte2e95bOCJHXTMfiC01f p0aAo97/8gHIsVRg93j6SrzYZqzUo9Y6izn4IJ3UD9WBrnsNP2jEIE8YPVSIdaq4BDlN Uh5qiBIVI8wLVD22iSGqnlU/DG2tFqZgsokBXywjRdiAuyuIdu1W7VtmpJHwXmG4j0CN zaNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@shipmail.org header.s=mail header.b=sbIhRX2J; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q10si2837350eda.293.2019.10.09.23.15.52; Wed, 09 Oct 2019 23:16:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@shipmail.org header.s=mail header.b=sbIhRX2J; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732735AbfJJGPL (ORCPT + 99 others); Thu, 10 Oct 2019 02:15:11 -0400 Received: from ste-pvt-msa1.bahnhof.se ([213.80.101.70]:49439 "EHLO ste-pvt-msa1.bahnhof.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726664AbfJJGPL (ORCPT ); Thu, 10 Oct 2019 02:15:11 -0400 Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTP id 1772C3F669; Thu, 10 Oct 2019 08:15:09 +0200 (CEST) Authentication-Results: ste-pvt-msa1.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=sbIhRX2J; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=6.31 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from ste-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (ste-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF_BPEmU0Hjj; Thu, 10 Oct 2019 08:15:08 +0200 (CEST) Received: from mail1.shipmail.org (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) (Authenticated sender: mb878879) by ste-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 9B3E83F382; Thu, 10 Oct 2019 08:15:04 +0200 (CEST) Received: from localhost.localdomain (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) by mail1.shipmail.org (Postfix) with ESMTPSA id D1CAF360162; Thu, 10 Oct 2019 08:15:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1570688103; bh=4ue4EqSxzXPPi4ag3sKg2WTH3PY+hWrK79ED1yBsa+0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=sbIhRX2JQ+of5RLA1KLI3iQ7xs3ubZLmjQuAA5owJXkEMaAF+3Wgh6UKoEZkI7KJo 66hjoJLEsbvXDc87+xAg1IhFKaHJEBhnegJnUKu4vAx/NNDexVYH+TUbDBPK5B2Vsd ohUzQ8JecXUJerZgrz2/9c6Rzc0OdurkQyVquwHk= Subject: Re: [PATCH v4 3/9] mm: pagewalk: Don't split transhuge pmds when a pmd_entry is present To: Linus Torvalds Cc: Thomas Hellstrom , "Kirill A. Shutemov" , Linux Kernel Mailing List , Linux-MM , Matthew Wilcox , Will Deacon , Peter Zijlstra , Rik van Riel , Minchan Kim , Michal Hocko , Huang Ying , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= References: <20191008091508.2682-1-thomas_os@shipmail.org> <20191008091508.2682-4-thomas_os@shipmail.org> <20191009152737.p42w7w456zklxz72@box> <03d85a6a-e24a-82f4-93b8-86584b463471@shipmail.org> <80f25292-585c-7729-2a23-7c46b3309a1a@shipmail.org> <6d3ef513-ca9d-9778-10da-86f368a57cd0@shipmail.org> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28VMware=29?= Organization: VMware Inc. Message-ID: <2899bd30-ca8a-3b44-8946-a69de8db7b93@shipmail.org> Date: Thu, 10 Oct 2019 08:15:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/10/19 4:07 AM, Linus Torvalds wrote: > On Wed, Oct 9, 2019 at 6:10 PM Thomas Hellström (VMware) > wrote: >> Your original patch does exactly the same! > Oh, no. You misread my original patch. > > Look again. > > The logic in my original patch was very different. It said that > > - *if* we have a pmd_entry function, then we obviously call that one. > > And if - after calling the pmd_entry function - we are still a > hugepage, then we skip the pte_entry case entirely. > > And part of skipping is obviously "don't split" - but it never had > that "don't split and then call the pte walker" case. > > - and if we *don't* have a pmd_entry function, but we do have a > pte_entry function, then we always split before calling it. > > Notice the difference? From what I can tell, my patch is doing the same. At least that always was the intention. To determine whether to skip pte and skip split, your patch uses /* No pte level at all? */ if (is_swap_pmd(*pmd) || pmd_trans_huge(*pmd) || pmd_devmap(*pmd)) continue; whereas my patch does             if (pmd_trans_unstable(pmd)) goto again; /* Fall through */ which is the same (pmd_trans_unstable() is the same test as you do, but not racy). Yes, it's missing the test for pmd_devmap() but I think that's an mm bug been discussed elsewhere, and we also rerun because a huge / none pmd at this (FALLBACK) point is probably a race and unintended. > > But I think the "change pmd_entry to have a sane return code" is a > simpler and more flexible model, and then the pmd_entry code can just > let the pte walker split the pmd if needed. OK, let's aim for that then. Thanks, Thomas > > So I liked that part of your patch. > > Linus