Messages in this thread | | | Date | Sat, 7 Mar 2015 11:12:50 -0800 | Subject | Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur | From | Linus Torvalds <> |
| |
On Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar <mingo@kernel.org> 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
| |