lkml.org 
[lkml]   [2018]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
On Tue, 20 Mar 2018, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@linutronix.de> 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.

Thanks,

tglx

\
 
 \ /
  Last update: 2018-03-20 10:41    [W:0.084 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site