Messages in this thread |  | | Date | Sat, 8 Jun 1996 20:21:15 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: Speed of memcpy, csum_partial and csum_partial_copy |
| |
On Sat, 8 Jun 1996, Alan Cox wrote: > > > My other point is that csum_partial_copy looks like it could run 33% > > faster, when everything is in the CPU cache, by rearranging the > > instructions in the loop to pair fully -- I think that adcl can pair but > > only in the U pipe. (I could be wrong about this. If adcl can pair > > anywhere, there are still write-then-read dependencies that prevent > > pairing in that code). > > Several people have sped the checksum/copy code up over time. If you can > speed it further then you will be number 4, and since the performance of > these routines is very critical then the patches will be welcome.
Just to show exactly _how_ important, here's some profiling info of a machine that has been busy doing TCP over loopback (everything >= 0.5% included):
14 0.51% 0010fe10 schedule 14 0.51% 00116194 do_bottom_half 14 0.51% 001365a0 kfree_skbmem 14 0.51% 00191288 csum_partial 15 0.55% 00118c48 do_no_page 15 0.55% 00142fd8 tcp_queue 15 0.55% 00144db8 tcp_send_ack 16 0.59% 00110494 add_timer 16 0.59% 0013ebb8 ip_queue_xmit 16 0.59% 0018ec70 loopback_xmit 17 0.62% 00121c8c get_empty_inode 17 0.62% 0013636c kfree_skb 17 0.62% 0014315c tcp_data 18 0.66% 001104c8 del_timer 19 0.70% 00138320 eth_type_trans 22 0.81% 00143c8c tcp_new_window 23 0.85% 0013734c net_bh 23 0.85% 00138134 eth_header 23 0.85% 0014405c tcp_write_xmit 26 0.96% 0011e8f4 _get_free_pages 26 0.96% 001365f0 skb_clone 31 1.14% 00136454 alloc_skb 34 1.25% 00140e5c tcp_recvmsg 40 1.47% 0011cf14 kmalloc 40 1.47% 001434a4 tcp_rcv 42 1.55% 0013e810 ip_build_header 45 1.66% 0013cb44 ip_rcv 45 1.66% 0014052c do_tcp_sendmsg 48 1.77% 001425e8 tcp_ack 54 1.99% 0011d114 kfree 643 23.78% 00191324 csum_partial_copy_fromuser 997 36.88% 001369c8 memcpy_toiovec 2703 100.00% 00000000 total
In short, the two copies that occur in TCP loopback (first from the sender into the kernel, and then from the kernel into the receiver) alone account for 60% of the TCP stack..
(This is on a P166 with a reasonably good memory subsystem, and the machine was sending 500MB of data over TCP loopback).
Oh, and the "kfree()" number actually is mostly "free_pages()" but due to running with interrupts disabled it shows up in kfree in case you were wondering - I did.
Linus
|  |