xfs
[Top] [All Lists]

Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur

To: Ingo Molnar <mingo@xxxxxxxxxx>
Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 7 Mar 2015 11:12:50 -0800
Cc: Mel Gorman <mgorman@xxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Aneesh Kumar <aneesh.kumar@xxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Linux-MM <linux-mm@xxxxxxxxx>, xfs@xxxxxxxxxxx, ppc-dev <linuxppc-dev@xxxxxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=etwRbcE+sl2HhB57rZ6cJ+PLJqA+nYzReYWg8sL0t18=; b=tUmY47WpGyDRDOLmc/psNiP2eC3YFVY5tBPxdoIRsmBOQsVBbFKlZgV9D+VrS1ObOM pvW8RNY82wobQVm30lR7IkeiHmoePc/U2hRvaigL4xmsEmtCSsjjwT9Jl0dBUCHKyYbi RIm7+SsF6odydqoKjT1BO1iQ6No8lmzcHAoOusgy3lelI5i14SCJPG89gtnDztFBUMYM kt4cEw0Hno6ExrPQ+Y7+LYM8Jyr2QQEdyAZ4HRrcmXye6s+isGJwSQJe+QKE379F3wEY TPQ/6OtXpKaF2Bc8qaRbWkNzi9ZkONVxBMZzJHjrMXjmwZCizKRmNygzvdcw2U0W3OI8 g2cg==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=etwRbcE+sl2HhB57rZ6cJ+PLJqA+nYzReYWg8sL0t18=; b=cd/79vPrmJZRsVexEbZFz5Rb8IWOnSYs3TbUJcjPxcFErPt/mRPMjJva1x5D6rcpH/ oXlH4JydqvPAO8qfuKaRGlg7xrLDyQBnEG9jjce3Xizqk/MeVugULOr7LrUrN1qg0tWO fEPgCryxvjBxtK05pJa1zAaqa2oNAoTojoaV8=
In-reply-to: <20150307163657.GA9702@xxxxxxxxx>
References: <1425741651-29152-1-git-send-email-mgorman@xxxxxxx> <1425741651-29152-5-git-send-email-mgorman@xxxxxxx> <20150307163657.GA9702@xxxxxxxxx>
Sender: linus971@xxxxxxxxx
On Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> And the patch Dave bisected to is a relatively simple patch.
> Why not simply revert it to see whether that cures much of the
> problem?

So the problem with that is that "pmd_set_numa()" and friends simply
no longer exist. So we can't just revert that one patch, it's the
whole series, and the whole point of the series.

What confuses me is that the only real change that I can see in that
patch is the change to "change_huge_pmd()". Everything else is pretty
much a 100% equivalent transformation, afaik. Of course, I may be
wrong about that, and missing something silly.

And the changes to "change_huge_pmd()" were basically re-done
differently by subsequent patches anyway.

The *only* change I see remaining is that change_huge_pmd() now does

   entry = pmdp_get_and_clear_notify(mm, addr, pmd);
   entry = pmd_modify(entry, newprot);
   set_pmd_at(mm, addr, pmd, entry);

for all changes. It used to do that "pmdp_set_numa()" for the
prot_numa case, which did just

   pmd_t pmd = *pmdp;
   pmd = pmd_mknuma(pmd);
   set_pmd_at(mm, addr, pmdp, pmd);

instead.

I don't like the old pmdp_set_numa() because it can drop dirty bits,
so I think the old code was actively buggy.

But I do *not* see why the new code would cause more migrations to happen.

There's probably something really stupid I'm missing.

                           Linus

<Prev in Thread] Current Thread [Next in Thread>