On Tue, May 19, 2015 at 04:41:19PM +0100, Mel Gorman wrote: > On Tue, May 19, 2015 at 05:27:10PM +0200, Michal Hocko wrote: > > On Tue 19-05-15 16:13:02, Mel Gorman wrote: > > [...] > > > :ffffffff811c160f: je ffffffff811c1630 > > > <mem_cgroup_try_charge+0x40> > > > :ffffffff811c1611: xor %eax,%eax > > > :ffffffff811c1613: xor %ebx,%ebx > > > 1 1.7e-05 :ffffffff811c1615: mov %rbx,(%r12) > > > 7 1.2e-04 :ffffffff811c1619: add $0x10,%rsp > > > 1211 0.0203 :ffffffff811c161d: pop %rbx > > > 5 8.4e-05 :ffffffff811c161e: pop %r12 > > > 5 8.4e-05 :ffffffff811c1620: pop %r13 > > > 1249 0.0210 :ffffffff811c1622: pop %r14 > > > 7 1.2e-04 :ffffffff811c1624: pop %rbp > > > 5 8.4e-05 :ffffffff811c1625: retq > > > :ffffffff811c1626: nopw %cs:0x0(%rax,%rax,1) > > > 295 0.0050 :ffffffff811c1630: mov (%rdi),%rax > > > 160703 2.6973 :ffffffff811c1633: mov %edx,%r13d > > > > Huh, what? Even if this was off by one and the preceding instruction has > > consumed the time. This would be reading from page->flags but the page > > should be hot by the time we got here, no? > > > > I would have expected so but it's not the first time I've seen cases where > examining the flags was a costly instruction. I suspect it's due to an > ordering issue or more likely, a frequent branch mispredict that is being > accounted for against this instruction. >
Which is plausible as forward branches are statically predicted false but in this particular load that could be a close to a 100% mispredict. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
