Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

From: Ingo Molnar
Date: Tue Apr 03 2018 - 06:37:07 EST



* Pavel Machek <pavel@xxxxxx> wrote:

> > > > 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.
>
> How is AVX2 supposed to help the memcpy speed?
>
> If the copy is small, constant overhead will dominate, and I don't
> think AVX2 is going to be win there.

There are several advantages:

1)

"REP; MOVS" (also called ERMS) has a significant constant "setup cost".

In the scheme I suggested (and if it's possible) then single-register AVX2 access
on the other hand has a setup cost on the "few cycles" order of magnitude.

2)

AVX2 have various non-temporary load and store behavioral variants - while "REP;
MOVS" doesn't (or rather, any such caching optimizations, to the extent they
exist, are hidden in the microcode).

> If the copy is big, well, the copy loop will likely run out of L1 and maybe even
> out of L2, and at that point speed of the loop does not matter because memory is
> slow...?

In many cases "memory" will be something very fast, such as another level of
cache. Also, on NUMA "memory" can also be something locally wired to the CPU -
again accessible at ridiculous bandwidths.

Nevertheless ERMS is probably wins for the regular bulk memcpy by a few percentage
points, so I don't think AVX2 is a win in the generic large-memcpy case, as long
as continued caching of both the loads and the stores is beneficial.

Thanks,

Ingo