Re: [patch] x86, mm: pass in 'total' to__copy_from_user_*nocache()

[Linus Torvalds]

On Wed, 25 Feb 2009, Ingo Molnar wrote:
> 
> The main artifact would be the unaligned edges around a bigger 
> write. In particular the tail portion of a big write will be 
> cached.

.. but I don't really agree that this is a problem.

Sure, it's "wrong", but does it actually matter? No. Is it worth adding 
complexity to existing interfaces for? I think not.

In general, I think that software should not mess with nontemporal stores. 
The thing is, software almost never knows enough about the CPU cache to 
make an intelligent choice.

So I didn't want to apply the nocache patches in the first place, but the 
performance numbers were pretty clear. I'll take "real numbers" over my 
personal dislikes any day. But now we have real numbers going the other 
way for small writes, and a patch to fix that.

But we have no amount of real numbers for the edge cases, and I don't 
think they matter. In fact, I don't think they _can_ matter, because it is 
inevitably always going to be an issue of "which CPU and which memory 
subsystem".

In other words, there is no "right" answer. There is no "perfect". But 
there is "we can fix the real numbers".

At the same time, we also do know:
 - caches work
 - CPU designers will continue to worry about the normal (cached) case, 
   and will do reasonable things with cache replacement.
 - ergo: w should always consider the cached case to be the _normal_ mode, 
   and it's the nontempral loads/stores that need to explain themselves.

So I do think we should just apply the simple patch. Not make a big deal 
out of it. We have numbers. We use cached memory copies for everything 
else. It's always "safe".

And we pretty much know that the only time we will ever really care about 
the nontemporal case is with big writes - where the "edge effects" 
essentially become total noise. 

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/