On Tue, Mar 17, 2015 at 3:08 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>>
>> Damn. From a performance number standpoint, it looked like we zoomed
>> in on the right thing. But now it's migrating even more pages than
>> before. Odd.
>
> Throttling problem, like Mel originally suspected?
That doesn't much make sense for the original bisect you did, though.
Although if there are two different issues, maybe that bisect was
wrong. Or rather, incomplete.
>> Can you do a simple stupid test? Apply that commit 53da3bc2ba9e ("mm:
>> fix up numa read-only thread grouping logic") to 3.19, so that it uses
>> the same "pte_dirty()" logic as 4.0-rc4. That *should* make the 3.19
>> and 4.0-rc4 numbers comparable.
>
> patched 3.19 numbers on this test are slightly worse than stock
> 3.19, but nowhere near as bad as 4.0-rc4:
>
> 241,718 migrate:mm_migrate_pages ( +- 5.17% )
Ok, that's still much worse than plain 3.19, which was ~55,000.
Assuming your memory/measurements were the same.
So apparently the pte_write() -> pte_dirty() check isn't equivalent at
all. My thinking that for the common case (ie private mappings) it
would be *exactly* the same, because all normal COW pages turn dirty
at the same time they turn writable (and, in page_mkclean_one(), turn
clean and read-only again at the same time). But if the numbers change
that much, then clearly my simplistic "they are the same in practice"
is just complete BS.
So why am I wrong? Why is testing for dirty not the same as testing
for writable?
I can see a few cases:
- your load has lots of writable (but not written-to) shared memory,
and maybe the test should be something like
pte_dirty(pte) || (vma->vm_flags & (VM_WRITE|VM_SHARED) ==
(VM_WRITE|VM_SHARED))
and we really should have some helper function for this logic.
- something completely different that I am entirely missing
What am I missing?
Linus
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
