lkml.org 
[lkml]   [2018]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [LKP] [lkp-robot] [iversion] c0cef30e4f: aim7.jobs-per-min -18.0% regression
From
Date


On 2018年02月28日 01:04, Linus Torvalds wrote:
> On Tue, Feb 27, 2018 at 5:43 AM, David Howells <dhowells@redhat.com> wrote:
>> Is it possible there's a stall between the load of RCX and the subsequent
>> instructions because they all have to wait for RCX to become available?
>
> No. Modern Intel big-core CPU's simply aren't that fragile. All these
> instructions should do OoO fine for trivial sequences like this, and
> as far as I can tell, the new code sequence should be better.
>
> And even if it were worse for some odd reason, it would be worse by a cycle.
>
> This kind of 18% change is something else, it is definitely not about
> instruction scheduling.
>
> Now, if the change to inode_cmp_iversion() causes some actual
> _behavioral_ changes, and we get more IO, that's more like it. But the
> code really does seem to be equivalent. In both cases it is simply
> comparing 63 bits: the high 63 bits of 0x150(%rbp) - inode->i_version
> - with the low 63 bits of 0x20(%rax) - iint->version.
>
> The only issue would be if the high bit of 0x20(%rax) was somehow set.
> The new code doesn't shift that bit away an more, but it should never
> be set since it comes from
>
> i_version = inode_query_iversion(inode);
> ...
> iint->version = i_version;
>
> and that inode_query_iversion() will have done the version shift.
>
>> The interleaving between operating on RSI and RCX in the older code might
>> alleviate that.
>>
>> In addition, the load if the 20(%rax) value is now done in the CMP instruction
>> rather than earlier, so it might not get speculatively loaded in time, whereas
>> the earlier code explicitly loads it up front.
>
> No again, OoO cores will generally hide details like that.
>
> You can see effects of it, but it's hard, and it can go both ways.
>
> Anyway, I think the _real_ change has nothing to with instruction
> scheduling, and everything to do with this:
>
> 107.62 ± 37% +139.1% 257.38 ± 16% vmstat.io.bo
> 48740 ± 36% +191.4% 142047 ± 16% proc-vmstat.pgpgout
>
> (There's fairly big variation in those numbers, but the changes are
> even bigger) or this:
>
> 258.12 -100.0% 0.00 turbostat.Avg_MHz
> 21.48 -21.5 0.00 turbostat.Busy%
>

This is caused by a limitation in current turbostat parse script of lkp. It
treats a string including wildcard character (e.g. 30.**) in the output of turbostat
monitor as an error and set all the stats value as 0.

Turbostat monitor runs successfully during these tests.

> or this:
>
> 27397 ±194% +43598.3% 11972338 ±139%
> latency_stats.max.io_schedule.nfs_lock_and_join_requests.nfs_updatepage.nfs_write_end.generic_perform_write.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
> 27942 ±189% +96489.5% 26989044 ±139%
> latency_stats.sum.io_schedule.nfs_lock_and_join_requests.nfs_updatepage.nfs_write_end.generic_perform_write.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
>
> but those all sound like something changed in the setup, not in the kernel.
>
> Odd.
>
> Linus
>

\
 
 \ /
  Last update: 2018-03-02 06:57    [W:0.069 / U:2.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site