lkml.org 
[lkml]   [1996]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.087 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site