zerocopy NFS for 2.5.36
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20020919.221513.28808421.taka@valinux.co.jp.suse.lists.linux.kernel
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Andrew Morton
Quoted 5 lines · Hirokazu Takahashi
...
Quoted 3 lines
It needs redoing. These differences are really big, and this is the kernel's most expensive function.
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
A little project for someone.
OK, if there is nobody who wants to do it I'll do it by myself.
That would be fantastic - thanks. This is more a measurement and testing exercise than a coding one. And if those measurements are sufficiently nice (eg: >5%) then a 2.4 backport should be done.
Very interesting IMHO would be to find a heuristic to switch between a write combining copy and a cache hot copy. Write combining is good for blasting huge amounts of data quickly without killing your caches. Cache hot is good for everything else.
But it'll need hints from the higher level code. e.g. read and write could turn on write combining for bigger writes (let's say >8K) I discovered that just unconditionally turning it on for all copies is not good because it forces data out of cache. But I still have hope that it helps for selected copies.
-Andi
Quoted 13 lines · Andi Kleen
Quoted 10 lines · Andrew Morton
Quoted 8 lines · Hirokazu Takahashi
...
Quoted 4 lines
It needs redoing. These differences are really big, and this is the kernel's most expensive function.
A little project for someone.
OK, if there is nobody who wants to do it I'll do it by myself.
Quoted 8 lines
Quoted 3 lines
That would be fantastic - thanks. This is more a measurement and testing exercise than a coding one. And if those measurements are sufficiently nice (eg: >5%) then a 2.4 backport should be done.
Very interesting IMHO would be to find a heuristic to switch between a write combining copy and a cache hot copy. Write combining is good for blasting huge amounts of data quickly without killing your caches. Cache hot is good for everything else.
I expect that caching userspace and not pagecache would be a reasonable choice.
Quoted 5 lines
But it'll need hints from the higher level code. e.g. read and write could turn on write combining for bigger writes (let's say >8K) I discovered that just unconditionally turning it on for all copies is not good because it forces data out of cache. But I still have hope that it helps for selected copies.
Well if it's a really big read then bypassing the CPU cache on the userspace-side buffer would make sense.
Can you control the cachability of the memory reads as well?
What restrictions are there on these instructions? Would they force us to bear the cost of the aligment problem?
Quoted 7 lines · Andrew Morton
Quoted 4 lines
Very interesting IMHO would be to find a heuristic to switch between a write combining copy and a cache hot copy. Write combining is good for blasting huge amounts of data quickly without killing your caches. Cache hot is good for everything else.
I expect that caching userspace and not pagecache would be a reasonable choice.
Normally yes, but not always. e.g. for squid you don't really want to cache user space.
But I guess it would be a reasonable heuristic. Or at least worth a try :-)
Quoted 11 lines
Quoted 6 lines
But it'll need hints from the higher level code. e.g. read and write could turn on write combining for bigger writes (let's say >8K) I discovered that just unconditionally turning it on for all copies is not good because it forces data out of cache. But I still have hope that it helps for selected copies.
Well if it's a really big read then bypassing the CPU cache on the userspace-side buffer would make sense.
Can you control the cachability of the memory reads as well?
SSE2 has hints for that (prefetchnti and even prefetcht0,1 etc. for different cache hierarchies), but it's not completely clear on how much
the CPUs follow these.
For writing it's much more obvious and usually documented even.
Quoted 3 lines
What restrictions are there on these instructions? Would they force us to bear the cost of the aligment problem?
They should be aligned, otherwise it makes no sense. When you assume it's more likely that one target or destination are unaligned then you can easily align either target or destination. Trick is to chose the right one, it varies on the call site.
(these are for big copies so a small alignment function is lost in the noise)
x86-64 copy_*_user currently aligns the destination, but hardcoding that is a bit dumb and I'm not completely happy with it.
-Andi
From: Andi Kleen <[email protected]>
Date: Fri, 20 Sep 2002 03:23:46 +0200
Quoted 1 line · Andrew Morton
Can you control the cachability of the memory reads as well?
SSE2 has hints for that (prefetchnti and even prefetcht0,1 etc. for different cache hierarchies), but it's not completely clear on how much the CPUs follow these.
For writing it's much more obvious and usually documented even.
See "montdq/movnti", the latter of which even works on register registers. Ben LaHaise pointed this out to me earlier today.
Quoted 2 lines
See "montdq/movnti", the latter of which even works on register registers. Ben LaHaise pointed this out to me earlier today.
The issue is that you really want to do prefetching in these loops (waiting for the hardware prefetch is too slow because it needs several cache misses to trigger) so for cache hints on reading only prefetch instructions are interesting.
-Andi
From: Andi Kleen <[email protected]>
Date: Fri, 20 Sep 2002 04:06:19 +0200
Quoted 2 lines
See "montdq/movnti", the latter of which even works on register registers. Ben LaHaise pointed this out to me earlier today.
The issue is that you really want to do prefetching in these loops (waiting for the hardware prefetch is too slow because it needs several cache misses to trigger) so for cache hints on reading only prefetch instructions are interesting.
I'm talking about using this to bypass the cache on the stores. The prefetches are a seperate issue and I agree with you on that.
Quoted 6 lines · David S. Miller
From: Andi Kleen <[email protected]>
Date: Fri, 20 Sep 2002 04:06:19 +0200Quoted 2 lines
See "montdq/movnti", the latter of which even works on register registers. Ben LaHaise pointed this out to me earlier today.
Quoted 7 lines
The issue is that you really want to do prefetching in these loops (waiting for the hardware prefetch is too slow because it needs several cache misses to trigger) so for cache hints on reading only prefetch instructions are interesting.
I'm talking about using this to bypass the cache on the stores. The prefetches are a seperate issue and I agree with you on that.
I was talking generally. You cannot really use these instructions on Athlon, because they're microcoded and slow or do not exist. On Athlon it needs 3dnow write combining functions (adding FPU overhead so may not be worth it). On P3/P4 you can use movnti/movntdq yes.
Just doing it for reads is more tricky/dubious.
-Andi
From: Andi Kleen <[email protected]>
Date: Fri, 20 Sep 2002 04:28:19 +0200
You cannot really use these instructions on Athlon,
I know that Athlon lacks these instructions, they are p4 sse2 only.
Quoted 7 lines · David S. Miller
From: Andi Kleen <[email protected]>
Date: Fri, 20 Sep 2002 04:28:19 +0200You cannot really use these instructions on Athlon,
I know that Athlon lacks these instructions, they are p4 sse2 only.
AFAIK it is an SSE1 feature.
Athlon actually has movnti in newer models, just you do not really want to use it.
-Andi