[lkml]   [2017]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Question Regarding ERMS memcpy
On Sat, Mar 04, 2017 at 04:56:38PM -0800, wrote:
> That's what the -march= and -mtune= option do!

How does that even help with a distro kernel built with -mtune=generic ?

gcc can't possibly know on what targets is that kernel going to be
booted on. So it probably does some universally optimal things, like in
the dmi_scan_machine() case:

memcpy_fromio(buf, p, 32);

turns into:

.loc 3 219 0
movl $8, %ecx #, tmp79
movq %rax, %rsi # p, p
movq %rsp, %rdi #, tmp77
rep movsl

Apparently it thinks it is fine to do 8*4-byte MOVS. But why not
4*8-byte MOVS?

That's half the loops.

[ It is a whole different story what the machine actually does underneath. It
being a half cacheline probably doesn't help and it really does the separate
MOVs but then it would be cheaper if it did 4 8-byte ones. ]

One thing's for sure - both variants are certainly cheaper than to CALL
a memcpy variant.

What we probably should try to do, though, is simply patch in the body
of REP; MOVSQ or REP; MOVSB into the call sites and only have a call to
memcpy_orig() because that last one if fat.

I remember we did talk about it at some point but don't remember why we
didn't do it.


SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

 \ /
  Last update: 2017-03-05 10:52    [W:0.086 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site