Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1203706ybp; Wed, 9 Oct 2019 10:18:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxAy6+/rtQ8jAvDYM5F+R+1UXSeMJ1uL9tRqU6F1gSWm9qeN6g120SYSSszbu726yoPby3S X-Received: by 2002:aa7:d045:: with SMTP id n5mr4052442edo.24.1570641491003; Wed, 09 Oct 2019 10:18:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570641490; cv=none; d=google.com; s=arc-20160816; b=07IJWE10quh+aB9LQEkq0ZLhbpw504lVFlFCsMqWT4U3KW2NSlHsfysSxvP88tqp0o 1Ska2n0CmxGas9xcSucBMdYMuBwYxn7jXI/utr48V4hc9ldb3YzRmdnjhGz9DdW4Rt+e GAUljVct8fpSIoaWqPIp+gYOScWlrm+NvJ4M90j07Cwp+6XqanSRBiEcjxL5eIpTswcb w/YuYjAUCCU8jhUY7DlfnIyGeJYJ++IhUattI7gMwZccydTuDOSB1y5+8Jbrkn1VC36Q 75CB1QfIWKhJEsZS4EBWhIn8XN1Th5mpRZJSODfiUFoL2GvVQBMqJzHRvnvjx/DuNZgP gFNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=WYDrRYPHs0j7kH6nvfHacya6cMEOhB6fPC+Nemlqhfc=; b=si98MS4HgPsaAN7lScBOKeJAK0PtLhzTMrKpCzDuE7jccdzNkuIrSuejoyr2ZhZkwa /Dca+XtFYFlGsJb/0CT+KXxeUI1KPU0FEII2mRBTqMxFSof4uJiLUgs0oY4//65W6+QG 2ekSm1VnWtNXX5wdhLGZWFWcgfale7hhAf6beiuZJqLQ0OXDmcsWNbbJkFbj9rJkiN3c b/gbqlq8KGMohpOW0VEsNE07tPzMtZxcAO7J82qooaPEnXGeX1+4w0WB4VKIT1Ti5aeM z6WLYoLM+pZatQtEqrHrSIH1GRjHax7ciUoeOL2qzWkTCc2l7dvLAIKS4W7x4VuVYBme nHLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=AOAkA+oy; 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 e48si2004525eda.130.2019.10.09.10.17.46; Wed, 09 Oct 2019 10:18:10 -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=pass header.i=@linux-foundation.org header.s=google header.b=AOAkA+oy; 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 S1732056AbfJIRRM (ORCPT + 99 others); Wed, 9 Oct 2019 13:17:12 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:42398 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731173AbfJIRRL (ORCPT ); Wed, 9 Oct 2019 13:17:11 -0400 Received: by mail-lj1-f195.google.com with SMTP id y23so3267691lje.9 for ; Wed, 09 Oct 2019 10:17:10 -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=WYDrRYPHs0j7kH6nvfHacya6cMEOhB6fPC+Nemlqhfc=; b=AOAkA+oySTesOPMVYaXrzFKziTaxffb4NvaLlldPxDNma8iMLawniVil20T4VPFBT/ lJMODrpuJPMyGcX5A2MSdkt5UwkF3L8ZbQNgFABx5dhefmgUO+tHZ4ey9D0lN9erNqVg hnHobkTbmoNLfTwLN96hilGvYMpN12W8DR9gI= 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=WYDrRYPHs0j7kH6nvfHacya6cMEOhB6fPC+Nemlqhfc=; b=j0yxFzv+Eo9AEphcPo3gKeqRr4geT2mY7bPAJioq91ceDtYRpc5wjiq/YbLwa6xiu1 0zOO3SMaB53yRGElqEFn27QguAkAkFiN5tPBH7cpKymjqI6WXLo7HNK+4tlzSUUOBUYf MnAFhDwsIcOU5QanqX3wymJHiW1MdZaVyGc8LL25VwPf3wHoY1Sg3Q0tG6CGnSWANQtU nmSPve7aROK/rbobAwVBf/iQ5ZGg29eHoYW0KrNz4yekKvwUuGfmcCf7uMnuHZt/t+uW nn1EbdwjTkQFtYkXhWdJIuB+R2wim8evF87V2hT65eajs/qf6s4UrO24VL4e0mHJDc26 JEEQ== X-Gm-Message-State: APjAAAXnbE9JHURTYDlXxqmWYCgi2uBHWYYJ5RC0pFUITw4WGTRzYCDo NSBELajnalwiUjLrDYSkXUeHbZspReg= X-Received: by 2002:a2e:98d8:: with SMTP id s24mr2973536ljj.72.1570641429405; Wed, 09 Oct 2019 10:17:09 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id m15sm568852ljh.50.2019.10.09.10.17.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Oct 2019 10:17:06 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id u28so2247049lfc.5 for ; Wed, 09 Oct 2019 10:17:06 -0700 (PDT) X-Received: by 2002:a19:6f0e:: with SMTP id k14mr2845221lfc.79.1570641426174; Wed, 09 Oct 2019 10:17:06 -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> In-Reply-To: <03d85a6a-e24a-82f4-93b8-86584b463471@shipmail.org> From: Linus Torvalds Date: Wed, 9 Oct 2019 10:16:49 -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: "Kirill A. Shutemov" , Linux Kernel Mailing List , Linux-MM , Thomas Hellstrom , 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 9, 2019 at 10:03 AM Thomas Hellstr=C3=B6m (VMware) wrote: > > Nope, it handles the hugepages by ignoring them, since they should be > read-only, but if pmd_entry() was called with something else than a > hugepage, then it requests the fallback, but never a split. But PAGE_WALK_FALLBACK _is_ a split. Oh, except you did this - split_huge_pmd(walk->vma, pmd, addr); + if (!ops->pmd_entry) + split_huge_pmd(walk->vma, pmd, addr); so it avoids the split. No, that's unacceptable. And makes no sense anyway. If it doesn't split the pmd, then it shouldn't walk the pte's - because they don't exist. And if it's not a hugepmd, then the split is a no-op, so the test makes no sense. I hadn't noticed that part of the patch. That simply can't be right. I don't think you've tested this, because you never actually have hugepages, do you? You didn't notice or realize that split_huge_pmd() just does that if (is_swap_pmd(*____pmd) || pmd_trans_huge(*____pmd) \ || pmd_devmap(*____pmd)) \ thing and doesn't do anythign at all if it's not huge. So no. That code makes no sense at all, and I didn't realize how senseless it was, becasue I stupidly missed that "make the split conditional" - which is insane and wrong - and I thought that you wanted PAGE_WALK_FALLBACK to split a pmd and fall back to per-pte entries, which is what the name implies. But that's not what you wanted at all. Just get rid of PAGE_WALK_FALLBACK entirely then, and make the rule be that a zero return value just means "split and do ptes". Which is what you want (see above why "split" simply is wrong, and isn't an issue for you anyway. That won't change any existing cases, since even if they do have a zero return value, they don't have a pte_entry() callback, so they won't do that "split and do ptes" anyway. Linus