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_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 0786CC47404 for ; Thu, 10 Oct 2019 02:13:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 28EEB20B7C for ; Thu, 10 Oct 2019 02:13:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="BeieFAWy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 28EEB20B7C 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 CBBDF8E0005; Wed, 9 Oct 2019 22:13:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C6D786B0005; Wed, 9 Oct 2019 22:13:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B83D28E0005; Wed, 9 Oct 2019 22:13:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id 985416B0003 for ; Wed, 9 Oct 2019 22:13:21 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 38B6E181AC9AE for ; Thu, 10 Oct 2019 02:13:21 +0000 (UTC) X-FDA: 76026253002.12.art51_57612a675eb10 X-HE-Tag: art51_57612a675eb10 X-Filterd-Recvd-Size: 7371 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Oct 2019 02:13:20 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id r2so3102376lfn.8 for ; Wed, 09 Oct 2019 19:13:20 -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:content-transfer-encoding; bh=LVTlFWjjXqkfqHeR1S0u6EjRM0YYyhBOrAMAs/nOEWk=; b=BeieFAWyjI1F3VJRLfbX4p2jjIhtEOLplHRHxqZshN8p2DRirvoI5LMUtdoTMVa0jF hNeeEl7AXyvjUh3O8eAOPH51FAs5ujKoALbPurD6W8Utd4Owa6wJx/+3HVjzZH2kn5KZ mdnrWEWC7X8bEP6QvZMTajKS25sCA3oFM31pg= 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:content-transfer-encoding; bh=LVTlFWjjXqkfqHeR1S0u6EjRM0YYyhBOrAMAs/nOEWk=; b=bA5wPSEKvOIrvAAa3oWfTaK2uV8dZN9BbCsVOD9TQ5ETEYh6uPo7R94Q5vArBSvBzz jzb8/PuShdE6r+ENlRjb0lXjfBRnuFoojYkOnlFT9g5MfRiOt3rfc9oIH9A9+uiETjWk Dx1tirOjqURvt4Baov3mW05IHIMDqY12Iap77Mj7x3zEJGr8DvwIi7mJsk9ZPGV2VpZg 4ee6VM/cuGtylebFqfpzem8Pvqg5faILIlL5Wh7eC07CeCxYnLPR8apRbafiphQqd9R5 4LEL3bRhrwX7vcqCp93/9qmZ2kieUCVIWlVvj6ufnjfF02QXvGmjQZc3PtlUAWhb26uZ VtoA== X-Gm-Message-State: APjAAAUqwF3SBkcZpBWDDnZhP9aKM8tSV6rSep5to8P228GsDTFA4pML BAi1fvCLU16JFgPOeAqERTEEKIqWYAk= X-Google-Smtp-Source: APXvYqyjlMGrH/kJR8256uv7WWYN9numBtLZYuHJzlnpV32TxuD5FS4H/zUcNAXnrglMqQ8W7d51Yw== X-Received: by 2002:a19:f712:: with SMTP id z18mr3543095lfe.166.1570673598195; Wed, 09 Oct 2019 19:13:18 -0700 (PDT) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com. [209.85.208.178]) by smtp.gmail.com with ESMTPSA id q26sm833716lfd.53.2019.10.09.19.13.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Oct 2019 19:13:17 -0700 (PDT) Received: by mail-lj1-f178.google.com with SMTP id b20so4494175ljj.5 for ; Wed, 09 Oct 2019 19:13:17 -0700 (PDT) X-Received: by 2002:a2e:29dd:: with SMTP id p90mr4334806ljp.26.1570673261288; Wed, 09 Oct 2019 19:07:41 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <6d3ef513-ca9d-9778-10da-86f368a57cd0@shipmail.org> From: Linus Torvalds Date: Wed, 9 Oct 2019 19:07:24 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 3/9] mm: pagewalk: Don't split transhuge pmds when a pmd_entry is present To: =?UTF-8?Q?Thomas_Hellstr=C3=B6m_=28VMware=29?= 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?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Wed, Oct 9, 2019 at 6:10 PM Thomas Hellstr=C3=B6m (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? So instead of looking at the return value of the pmd_entry() function, the approach of that suggested patch was to basically say that if the pmd_entry function wants us to go another level deeper and it was a hugepmd, it needed to split the pmd to make that happen. That's actually very different from what your patch did. My original patch never tried to walk the pte level without having one - either it *checked* that it had one, or it split. But I see where you might have misread the patch, particularly if you only looked at it as a patch, not as the end result of the patch. The end result of that patch was this: if (ops->pmd_entry) { err =3D ops->pmd_entry(pmd, addr, next, walk); if (err) break; /* No pte level walking? */ if (!ops->pte_entry) continue; /* No pte level at all? */ if (is_swap_pmd(*pmd) || pmd_trans_huge(*pmd) || pmd_devmap(*pmd)) continue; } else { if (!ops->pte_entry) continue; split_huge_pmd(walk->vma, pmd, addr); if (pmd_trans_unstable(pmd)) goto again; } err =3D walk_pte_range(pmd, addr, next, walk); and look at thew two different sides of the if-statement: if they get to "walk_pte_range()", both cases wil have verified that there actually _is_ a pte level. They will just have done it differently. - the "we didn't have a pmd function" will have split the pmd if it was a hugepmd, while the "we do have a pmd_entry" case will just check whether it's still a huge-pmd, and done a "continue" if it was and never even tried to walk the ptes. 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. So I liked that part of your patch. Linus