From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access Date: Tue, 20 Mar 2018 11:54:27 +0100 Message-ID: <20180320105427.bm4od7cpessbraag@gmail.com> References: <7f0ddb3678814c7bab180714437795e0@AcuMS.aculab.com> <7f8d811e79284a78a763f4852984eb3f@AcuMS.aculab.com> <20180320082651.jmxvvii2xvmpyr2s@gmail.com> <20180320090802.qw4tqjmhy6yfd6sf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Laight , 'Rahul Lakkireddy' , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "mingo@redhat.com" , "hpa@zytor.com" , "davem@davemloft.net" , "akpm@linux-foundation.org" , "torvalds@linux-foundation.org" , "ganeshgr@chelsio.com" , "nirranjan@chelsio.com" , "indranil@chelsio.com" , Andy Lutomirski , Peter Zijlstra , Fenghua Yu , Eric Biggers To: Thomas Gleixner Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org * Thomas Gleixner wrote: > On Tue, 20 Mar 2018, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > > > > > > So I do think we could do more in this area to improve driver performance, if the > > > > code is correct and if there's actual benchmarks that are showing real benefits. > > > > > > If it's about hotpath performance I'm all for it, but the use case here is > > > a debug facility... > > > > > > And if we go down that road then we want a AVX based memcpy() > > > implementation which is runtime conditional on the feature bit(s) and > > > length dependent. Just slapping a readqq() at it and use it in a loop does > > > not make any sense. > > > > Yeah, so generic memcpy() replacement is only feasible I think if the most > > optimistic implementation is actually correct: > > > > - if no preempt disable()/enable() is required > > > > - if direct access to the AVX[2] registers does not disturb legacy FPU state in > > any fashion > > > > - if direct access to the AVX[2] registers cannot raise weird exceptions or have > > weird behavior if the FPU control word is modified to non-standard values by > > untrusted user-space > > > > If we have to touch the FPU tag or control words then it's probably only good for > > a specialized API. > > I did not mean to have a general memcpy replacement. Rather something like > magic_memcpy() which falls back to memcpy when AVX is not usable or the > length does not justify the AVX stuff at all. OK, fair enough. Note that a generic version might still be worth trying out, if and only if it's safe to access those vector registers directly: modern x86 CPUs will do their non-constant memcpy()s via the common memcpy_erms() function - which could in theory be an easy common point to be (cpufeatures-) patched to an AVX2 variant, if size (and alignment, perhaps) is a multiple of 32 bytes or so. Assuming it's correct with arbitrary user-space FPU state and if it results in any measurable speedups, which might not be the case: ERMS is supposed to be very fast. So even if it's possible (which it might not be), it could end up being slower than the ERMS version. Thanks, Ingo