Re: writev performance
Re: writev performance
- Subject: Re: writev performance
- From: Michael Smith <email@hidden>
- Date: Sun, 7 Feb 2010 03:29:20 -0800
On Feb 7, 2010, at 1:35 AM, Godfrey van der Linden wrote: I've been doing a little bit of coding using UDP protocols recently and tripped over the sendto api that takes two user land addresses: a data address and a sockaddr pointer. I realised that this means that two uio_copyin transfers needs to be made, this then made me wonder about the general efficiency of writev style system calls.
I have been using as a rule of thumb that limiting accesses to the vm system is a guaranteed way of increasing performance as the Mach VM system has been slow. It seems then if we have more than one uio interaction with user addresses copying data into the kernel we are multiply the number of vm interactions, and that is bad.
Given how fast modern processors can move memory wouldn't it be better to copy the vector of data into a single transfer buffer into the kernel. This means that the processor caches are nice and hot and everything is ready to go when the single transfer into the kernel goes, this seems to me to be probably faster. I haven't run any experiments yet but I'm sort of interested in your ideas. I'm pretty sure that the 4Gbyte KVA on 32 bit is going to make the uio_copyin() operations relatively expensive, but what about the 64bit kernels do they naturally have better access to user space mappings?
Thoughts?
Keep your eyes on the L1/L2.
Note that if you've touched the memory recently, you can win in many cases (e.g. ARM with ASIDs, some x86 cases with shared pagetables or pagetable caching evil) but in general doing scatter/gather in userspace for small operations will be a win.
= Mike
-- The lyf so short, the craft so long to lerne -- Chaucer
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden