Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1592718
| From | Borislav Petkov <bp@suse.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Question Regarding ERMS memcpy |
| Date | 2017-03-05 11:00 +0100 |
| Message-ID | <thB7k-6NF-3@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <thrKF-8kZ-11@gated-at.bofh.it> <ths41-gf-3@gated-at.bofh.it> <thsdH-jy-1@gated-at.bofh.it> <thsno-mO-7@gated-at.bofh.it> <thsGJ-vv-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sat, Mar 04, 2017 at 04:56:38PM -0800, hpa@zytor.com 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.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Question Regarding ERMS memcpy Logan Gunthorpe <logang@deltatee.com> - 2017-03-04 22:20 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-04 23:50 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-05 01:00 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 01:20 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-05 01:30 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 01:40 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-05 02:00 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 11:00 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 12:20 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 14:10 +0100
Re: Question Regarding ERMS memcpy Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-05 20:30 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 21:20 +0100
Re: Question Regarding ERMS memcpy Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-05 21:20 +0100
Re: Question Regarding ERMS memcpy Logan Gunthorpe <logang@deltatee.com> - 2017-03-06 08:10 +0100
Re: Question Regarding ERMS memcpy "H. Peter Anvin" <hpa@zytor.com> - 2017-03-06 08:40 +0100
Re: Question Regarding ERMS memcpy Logan Gunthorpe <logang@deltatee.com> - 2017-03-06 18:50 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-06 20:10 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-06 14:40 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-06 14:50 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-06 15:10 +0100
Re: Question Regarding ERMS memcpy Logan Gunthorpe <logang@deltatee.com> - 2017-03-05 06:00 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 11:00 +0100
csiph-web