Messages in this thread | | | From | "Manfred Spraul" <> | Subject | zerocopy pipe, new version | Date | Sat, 5 Jan 2002 23:27:25 +0100 |
| |
Attached is a new version of the zerocopy pipe code.
A few months ago, Hubertus Franke found a severe performance problem with my last version. Now I figured out how I can solve it: For good pipe performance, sys_read() must try to return as much data as possible with one syscall, even if the writer writes small bits. The current code uses PIPE_WAITING_WRITERS, but that doesn't work with nonblocking IO and is not that efficient.
I added a sched_yield() into that path, and that fixed the performance degradation: if pipe_read made progress and the user wants even more data, then call sched_yield() and give the writers a chance to write additional data. After sched_yield() returns, try again until there is either no more data, or the user request is completely fullfilled. Then return to userspace.
Now I got +50% on UP with pipeflex -c2 -r32 -w1 with 2.5.2-pre8+zerocopy, SMP kernel over 2.4.2-UP.
Unfortunately the patch has virtually no effect on 4 kB write-4 kB read, and that's the most common case. (number of context switches cut in half, but a slight performance loss on K6, probably due to cache trashing)
The only solution I see for that problem are larger kernel buffers - more data must be queued in kernel. Either on-demand (kmalloc() up to <sysctl-limit, around 512 kB> if a request for <= 4096 bytes arrives and would block. If the allocation fails, then block), or at pipe creation like in Hubertus' patch.
-- Manfred [unhandled content-type:application/octet-stream] | |