Re: x86-64: memset()/memcpy() not fully standards compliant

[Andi Kleen <andi@firstfloor.org>]

> I checked the most recent K8 (Hammer) and Pentium4 documentation,
> and didn't find mention of anything related. So pointing out where you

Sorry don't really plan to do any errata archaeology for this folly.

Maybe it got fixed in the latest versions, I remember them being there
on some early ones at least.

> >> > so making any of that slower is not a good idea.
> >> > 
> >> 
> >> Obviously not, but I'm perfectly fine turning REP_GOOD off on old broken
> >> CPUs.
> > 
> > That would be even worse.
> 
> How could you allow a CPU fall under REP_GOOD is its rep
> implementation is buggy.

The kernel never does >4GB copies, memsets, so it's not buggy.
It's just like any other obscure errata that doesn't matter because
it's not exercised.

REP_GOOD just means "string instructions are faster for 4K operations"

> 
> > You would slow a critical fast path operation down for something
> > that never happens?!?
> 
> It does happen, just (so far) not in-tree. It's a latent problem that's
> just waiting for someone else to run into. Apart from large bootmem
> allocations (where not even the latency of the memory clearing

Modern kernels are bootmem less.

> matters in any way, there's nothing I know of that would prevent
> someone from vmalloc()-ing a huge block of memory and then
> calling memset() on it (which ought to be tolerable in a preemptable
> kernel at least).

I bet there are more "int"s in the allocators and other code. It would
surprise me if it worked even with a changed memset.

Besides it obviously would be a bad idea on non preemptive kernels,
and since that can always happen it would be bad code, hopefully
never hitting any trees.

If you need it in Xen please just add the cmps there.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.