* tuning linux for high network performance?
@ 2002-10-23 10:18 Roy Sigurd Karlsbakk
2002-10-23 11:06 ` [RESEND] " Roy Sigurd Karlsbakk
0 siblings, 1 reply; 39+ messages in thread
From: Roy Sigurd Karlsbakk @ 2002-10-23 10:18 UTC (permalink / raw)
To: netdev; +Cc: Kernel mailing list
hi
I've got this video server serving video for VoD. problem is the P4 1.8 seems
to be maxed out by a few system calls. The below output is for ~50 clients
streaming at ~4.5Mbps. if trying to increase this to ~70, the CPU maxes out.
Does anyone have an idea?
bash-2.05# readprofile | sort -rn +2 | head -30
154203 default_idle 2409.4219
212723 csum_partial_copy_generic 916.9095
100164 handle_IRQ_event 695.5833
24979 system_call 390.2969
37300 e1000_intr 388.5417
119699 ide_intr 340.0540
30598 skb_release_data 273.1964
40740 do_softirq 195.8654
131818 do_wp_page 164.7725
9935 fget 155.2344
24747 kfree 154.6687
10911 del_timer 113.6562
11683 ip_conntrack_find_get 91.2734
4120 sock_poll 85.8333
9357 ip_ct_find_proto 83.5446
5194 sock_wfree 81.1562
4929 add_wait_queue 77.0156
8361 flush_tlb_page 74.6518
4571 remove_wait_queue 71.4219
2191 __brelse 68.4688
29477 skb_clone 68.2338
8562 do_gettimeofday 59.4583
5673 process_timeout 59.0938
11097 tcp_v4_send_check 57.7969
6124 kfree_skbmem 54.6786
17115 tcp_poll 53.4844
21130 nf_hook_slow 52.8250
8299 ip_ct_refresh 51.8687
15429 __kfree_skb 50.7533
1059 lru_cache_del 46.0435
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [RESEND] tuning linux for high network performance?
2002-10-23 10:18 tuning linux for high network performance? Roy Sigurd Karlsbakk
@ 2002-10-23 11:06 ` Roy Sigurd Karlsbakk
2002-10-23 13:01 ` bert hubert
2002-10-23 18:01 ` [RESEND] tuning linux for high network performance? Denis Vlasenko
0 siblings, 2 replies; 39+ messages in thread
From: Roy Sigurd Karlsbakk @ 2002-10-23 11:06 UTC (permalink / raw)
To: netdev; +Cc: Kernel mailing list
> I've got this video server serving video for VoD. problem is the P4 1.8
> seems to be maxed out by a few system calls. The below output is for ~50
> clients streaming at ~4.5Mbps. if trying to increase this to ~70, the CPU
> maxes out.
>
> Does anyone have an idea?
...adding the whole profile output - sorted by the first column this time...
905182 total 0.4741
121426 csum_partial_copy_generic 474.3203
93633 default_idle 1800.6346
74665 do_wp_page 111.1086
65857 ide_intr 184.9916
53636 handle_IRQ_event 432.5484
21973 do_softirq 107.7108
20498 e1000_intr 244.0238
19800 do_page_fault 16.8081
19395 skb_clone 45.7429
14564 system_call 260.0714
13592 kfree 89.4211
13557 skb_release_data 116.8707
13025 ide_do_request 17.6970
12988 do_rw_disk 8.4557
11841 tcp_sendmsg 2.6814
11720 nf_hook_slow 29.0099
11712 tcp_poll 34.0465
10688 schedule 7.8588
10386 __kfree_skb 34.1645
10052 ipt_do_table 10.1741
8286 fget 115.0833
7436 tcp_v4_send_check 44.2619
7191 e1000_clean_tx_irq 16.6458
7031 kmalloc 18.1211
6610 tcp_write_xmit 9.3892
6241 tcp_clean_rtx_queue 8.0425
6232 ip_conntrack_find_get 51.9333
6140 ide_dmaproc 8.4341
6125 tcp_packet 14.0482
5858 qdisc_restart 15.4158
5734 e1000_xmit_frame 5.6660
5709 tcp_v4_rcv 3.7363
5703 sys_rt_sigprocmask 11.4060
5445 tcp_transmit_skb 3.7500
5273 alloc_skb 11.8761
4961 ide_wait_stat 18.7917
4790 ip_ct_find_proto 44.3519
4782 add_timer 18.3923
4760 ip_ct_refresh 29.7500
4729 do_anonymous_page 17.6455
4616 e1000_clean_rx_irq 4.9106
4464 do_gettimeofday 37.2000
4359 flush_tlb_page 38.9196
4209 ip_finish_output2 16.4414
3731 get_hash_table 23.3188
3714 eth_type_trans 21.1023
3712 __make_request 2.3375
3680 __ip_conntrack_find 12.7778
3480 ip_route_input 9.1579
3363 kfree_skbmem 32.3365
3295 __switch_to 15.2546
3205 fput 13.1352
3143 rmqueue 5.3452
3137 ip_conntrack_in 5.0272
3008 sync_timers 250.6667
2861 sock_wfree 47.6833
2580 ip_queue_xmit 2.0347
2578 process_timeout 26.8542
2577 netif_rx 6.1357
2555 get_user_pages 6.2623
2504 sock_poll 62.6000
2346 ide_build_sglist 5.6394
2316 brw_kiovec 2.5619
2256 csum_partial 7.8333
2251 ip_queue_xmit2 4.2958
2198 start_request 4.0404
2186 dev_queue_xmit 2.7462
2167 timer_bh 2.2203
2162 __free_pages_ok 3.1608
2157 zap_page_range 2.4400
1942 mark_dirty_kiobuf 21.1087
1733 process_backlog 5.9349
1719 tcp_rcv_established 0.8493
1689 add_wait_queue 32.4808
1650 mod_timer 6.1567
1603 wait_kio 17.4239
1575 net_rx_action 4.8611
1554 get_pid 4.0052
1434 lru_cache_add 12.8036
1429 handle_mm_fault 7.7663
1397 ip_local_deliver_finish 4.5357
1357 nf_iterate 10.2803
1350 e1000_alloc_rx_buffers 5.2734
1298 do_select 2.5155
1268 unlock_page 12.1923
1209 submit_bh 10.7946
1184 add_entropy_words 5.9200
1175 __brelse 36.7188
1125 __pollwait 7.8125
1108 shrink_list 5.7708
1099 generic_make_request 3.6151
1080 __free_pages 33.7500
1052 tcp_ack 1.2524
1020 ip_rcv 1.0851
986 raid0_make_request 2.9345
898 ext3_direct_io_get_block 4.7766
883 pfifo_fast_dequeue 11.6184
863 sys_gettimeofday 5.5321
828 tcp_ack_update_window 3.9808
813 ipt_local_out_hook 7.8173
761 __lru_cache_del 6.5603
756 sys_write 2.9531
742 __rdtsc_delay 26.5000
730 uhci_interrupt 3.3182
718 net_tx_action 2.5643
710 batch_entropy_store 3.9444
701 add_timer_randomness 3.3066
666 tasklet_hi_action 4.1625
662 sys_nanosleep 1.7796
635 set_page_dirty 5.4741
627 __tcp_data_snd_check 3.1350
611 netif_receive_skb 1.9094
601 pfifo_fast_enqueue 5.3661
590 del_timer_sync 4.3382
587 lru_cache_del 26.6818
574 get_unmapped_area 2.1103
561 wait_for_tcp_memory 0.7835
557 ip_refrag 5.8021
546 ip_conntrack_local 6.2045
515 sys_select 0.4486
507 __tcp_select_window 2.2634
481 ext3_get_branch 2.2689
433 ip_output 1.2301
389 ip_confirm 9.7250
384 find_vma 4.5714
379 set_bh_page 9.4750
376 tcp_v4_do_rcv 1.0108
370 tcp_ack_no_tstamp 1.4453
368 batch_entropy_process 2.0000
365 ide_build_dmatable 1.1551
364 ip_rcv_finish 0.7696
363 kmem_cache_free 2.8359
362 __wake_up 1.8854
338 ext3_get_block_handle 0.5152
336 inet_sendmsg 5.2500
318 bh_action 2.3382
298 tcp_data_queue 0.1064
272 md_make_request 2.6154
272 ext3_block_to_path 0.9714
248 sock_sendmsg 1.8235
244 __alloc_pages 0.6932
238 kmem_cache_alloc 0.7532
226 __free_pte 3.1389
225 tcp_ack_probe 1.3720
224 __run_task_queue 2.0741
213 ide_get_queue 5.3250
209 __ip_ct_find_proto 4.3542
202 get_sample_stats 1.7414
195 tcp_write_space 1.6810
185 schedule_timeout 1.1859
184 do_signal 0.2992
182 ipt_hook 4.5500
171 generic_direct_IO 0.5552
168 can_share_swap_page 1.8261
157 ip_local_deliver 0.3965
155 get_conntrack_index 2.7679
145 tcp_push_one 0.5664
145 ide_set_handler 1.2500
144 pipe_poll 1.4400
143 max_select_fd 0.8938
139 pte_alloc 0.5792
138 del_timer 1.6429
136 sock_write 0.7234
131 poll_freewait 1.9265
131 getblk 1.7237
130 send_sig_info 0.8553
128 __release_sock 1.4545
125 ret_from_sys_call 7.3529
120 ext3_direct_IO 0.1807
118 tcp_pkt_to_tuple 3.6875
117 find_vma_prev 0.6648
114 do_no_page 0.2298
112 tqueue_bh 4.0000
112 follow_page 1.0769
110 bread 1.1000
108 e1000_rx_checksum 1.2273
107 generic_file_direct_IO 0.1938
102 add_interrupt_randomness 2.5500
97 remove_wait_queue 1.7321
96 mark_page_accessed 2.0000
91 kill_something_info 0.2645
85 invert_tuple 1.9318
81 exit_notify 0.1151
81 cpu_idle 0.9643
80 tcp_new_space 0.6061
79 nf_register_queue_handler 0.5197
75 uhci_remove_pending_qhs 0.3906
69 pdc202xx_dmaproc 0.1250
68 sys_read 0.2656
68 nf_reinject 0.1491
66 map_user_kiobuf 0.2619
65 find_vma_prepare 0.6500
64 generic_file_read 0.2353
61 check_pgt_cache 2.5417
60 free_pages 1.8750
58 error_code 0.9667
57 vm_enough_memory 0.5481
56 __delay 1.4000
55 __const_udelay 1.0577
53 tcp_ioctl 0.0908
53 journal_commit_transaction 0.0132
53 do_munmap 0.0901
52 _alloc_pages 2.1667
51 uhci_finish_completion 0.4554
51 credit_entropy_store 1.1591
50 rh_report_status 0.1953
50 free_page_and_swap_cache 0.8929
49 sys_rt_sigsuspend 0.1750
49 nr_free_pages 0.6125
49 do_mmap_pgoff 0.0394
48 e1000_update_stats 0.0307
48 do_get_write_access 0.0366
48 __journal_file_buffer 0.0916
48 __get_free_pages 2.0000
48 .text.lock.e1000_main 1.7143
47 expand_kiobuf 0.3092
46 uhci_free_pending_qhs 0.4600
46 tcp_parse_options 0.0833
46 kmem_cache_size 5.7500
45 rb_erase 0.2083
44 unmap_kiobuf 0.6111
41 tcp_cwnd_application_limited 0.3106
41 rh_int_timer_do 0.1165
41 init_or_cleanup 0.1424
40 sync_unlocked_inodes 0.0901
40 init_buffer 1.4286
39 .text.lock.ip_input 1.0000
38 vma_merge 0.1301
38 pfifo_fast_requeue 0.6786
38 ip_conntrack_get 0.9500
38 dev_watchdog 0.2209
37 .text.lock.ip_output 0.2803
36 do_check_pgt_cache 0.1731
35 tcp_retrans_try_collapse 0.0576
35 journal_add_journal_head 0.1306
34 ext3_get_inode_loc 0.0914
33 journal_write_revoke_records 0.1964
32 fsync_buffers_list 0.0860
31 filemap_fdatasync 0.1615
31 __pmd_alloc 1.5500
30 sys_wait4 0.0305
30 restore_sigcontext 0.0949
29 sys_sigreturn 0.1169
28 tcp_fastretrans_alert 0.0224
28 do_settimeofday 0.1628
28 do_ide_request 1.4000
27 unmap_fixup 0.0785
27 find_extend_vma 0.1350
27 eth_header_parse 0.8438
27 current_capacity 0.6750
26 save_i387 0.0478
26 __journal_clean_checkpoint_list 0.2407
25 update_atime 0.3125
25 tcp_v4_destroy_sock 0.0718
25 link_path_walk 0.0102
25 buffer_insert_inode_queue 0.2841
25 __journal_unfile_buffer 0.0665
24 sys_mmap2 0.1622
24 rh_send_irq 0.0896
24 rb_insert_color 0.1224
24 ext3_do_update_inode 0.0261
24 balance_dirty_state 0.3158
24 add_wait_queue_exclusive 0.4615
24 __try_to_free_cp_buf 0.4000
23 free_kiobuf_bhs 0.2396
22 tcp_rcv_synsent_state_process 0.0169
22 sys_munmap 0.2619
22 start_this_handle 0.0598
22 sock_rfree 1.3750
22 setup_sigcontext 0.0743
22 flush_tlb_mm 0.1964
22 do_exit 0.0301
22 alloc_kiobuf_bhs 0.1170
22 __rb_erase_color 0.0567
21 tcp_mem_schedule 0.0477
21 setup_frame 0.0482
21 __generic_copy_to_user 0.3500
20 unlock_buffer 0.3125
20 journal_write_metadata_buffer 0.0240
20 d_lookup 0.0704
20 copy_skb_header 0.0980
19 sync_old_buffers 0.1218
19 sock_mmap 0.4750
19 skb_split 0.0344
19 select_bits_alloc 0.7917
19 get_info_ptr 0.2065
17 tcp_write_wakeup 0.0363
17 ret_from_exception 0.6800
17 kiobuf_wait_for_io 0.1062
17 journal_unlock_journal_head 0.1518
17 bad_signal 0.1250
16 tcp_probe_timer 0.0952
16 tcp_close 0.0083
16 ip_route_output_slow 0.0099
16 __mark_inode_dirty 0.0952
16 .text.lock.timer 0.1250
16 .text.lock.tcp 0.0152
15 journal_cancel_revoke 0.0765
15 ext3_bmap 0.1500
15 do_fork 0.0074
15 blk_grow_request_list 0.0833
14 tcp_v4_conn_request 0.0145
14 sync_supers 0.0507
14 log_start_commit 0.0946
14 lock_vma_mappings 0.3500
14 journal_dirty_metadata 0.0354
14 file_read_actor 0.0625
14 __insert_vm_struct 0.1400
13 tcp_time_to_recover 0.0290
13 sys_ioctl 0.0259
13 lookup_swap_cache 0.1625
13 ip_build_xmit_slow 0.0099
13 invalidate_inode_pages 0.0739
13 ext3_dirty_inode 0.0478
13 bmap 0.2955
12 tcp_collapse 0.0143
12 sys_socketcall 0.0234
12 put_filp 0.1364
12 make_pages_present 0.0968
12 journal_get_write_access 0.1304
12 generic_file_write 0.0061
12 e1000_ioctl 0.3333
11 uhci_transfer_result 0.0316
11 tcp_try_to_open 0.0348
11 tcp_recvmsg 0.0045
11 tcp_create_openreq_child 0.0092
11 sys_kill 0.1250
11 schedule_tail 0.0786
11 osync_buffers_list 0.0859
11 journal_stop 0.0255
11 do_sigpending 0.0887
10 tcp_unhash 0.0397
10 tcp_send_probe0 0.0424
10 tcp_rcv_state_process 0.0040
10 sys_poll 0.0138
10 inet_shutdown 0.0208
10 execute_drive_cmd 0.0221
10 __put_unused_buffer_head 0.1136
9 tcp_write_timer 0.0395
9 tcp_send_skb 0.0191
9 tcp_make_synack 0.0082
9 set_buffer_flushtime 0.4500
9 raid0_status 0.2045
9 copy_page_range 0.0205
8 kupdate 0.0274
8 journal_get_descriptor_buffer 0.0741
8 get_empty_filp 0.0253
8 ext3_write_super 0.0741
8 count_active_tasks 0.1111
8 atomic_dec_and_lock 0.1111
8 __lock_page 0.0400
8 __journal_remove_journal_head 0.0250
8 __ip_conntrack_confirm 0.0115
8 __block_prepare_write 0.0105
7 tcp_invert_tuple 0.2188
7 ports_active 0.1346
7 pipe_write 0.0112
7 kjournald 0.0130
7 handle_signal 0.0273
7 grow_buffers 0.0254
7 ext3_get_block 0.0700
7 balance_classzone 0.0151
7 __jbd_kmalloc 0.0625
7 .text.lock.swap 0.1296
6 vsnprintf 0.0057
6 tcp_v4_send_reset 0.0176
6 tcp_accept 0.0105
6 sleep_on 0.0500
6 select_bits_free 0.3750
6 pipe_read 0.0118
6 number 0.0055
6 ip_route_output_key 0.0165
6 inet_accept 0.0136
6 get_unused_buffer_head 0.0375
6 dput 0.0176
6 cleanup_rbuf 0.0273
6 __journal_remove_checkpoint 0.0556
6 __journal_drop_transaction 0.0087
6 __find_get_page 0.0938
6 .text.lock.netfilter 0.0260
5 vmtruncate_list 0.0625
5 vfs_permission 0.0208
5 tcp_v4_hnd_req 0.0147
5 tcp_init_cwnd 0.0500
5 tcp_check_urg 0.0158
5 tcp_check_sack_reneging 0.0240
5 sys_fork 0.1786
5 sock_setsockopt 0.0034
5 sock_init_data 0.0161
5 sock_def_readable 0.0521
5 release_x86_irqs 0.0595
5 release_task 0.0109
5 refile_buffer 0.1389
5 pipe_release 0.0368
5 path_init 0.0129
5 nr_free_buffer_pages 0.0625
5 mprotect_fixup 0.0043
5 log_space_left 0.1562
5 ll_rw_block 0.0119
5 journal_start 0.0272
5 init_bh 0.2083
5 get_zeroed_page 0.1389
5 ext3_commit_write 0.0078
5 e1000_tx_timeout 0.2500
5 do_poll 0.0227
5 bdfind 0.1389
5 add_keyboard_randomness 0.1250
5 __wait_on_buffer 0.0338
5 __vma_link 0.0284
5 __tcp_mem_reclaim 0.0595
5 __rb_rotate_left 0.0781
4 write_profile 0.0244
4 tcp_v4_syn_recv_sock 0.0064
4 tcp_v4_search_req 0.0278
4 tcp_v4_route_req 0.0192
4 tcp_v4_init_sock 0.0169
4 tcp_cwnd_restart 0.0263
4 tcp_check_req 0.0043
4 tcp_check_reno_reordering 0.0500
4 sys_mprotect 0.0078
4 strncpy_from_user 0.0500
4 sock_def_wakeup 0.0625
4 sock_alloc 0.0208
4 skb_copy_datagram_iovec 0.0071
4 lookup_mnt 0.0476
4 locks_remove_posix 0.0096
4 invalidate_inode_buffers 0.0370
4 init_conntrack 0.0043
4 halfMD4Transform 0.0068
4 find_or_create_page 0.0164
4 filp_close 0.0238
4 ext3_reserve_inode_write 0.0233
4 ext3_find_goal 0.0213
4 do_fcntl 0.0059
4 dnotify_flush 0.0345
4 d_alloc 0.0105
4 add_blkdev_randomness 0.0526
4 _stext 0.0500
4 __journal_insert_checkpoint 0.0167
4 __find_lock_page_helper 0.0323
4 .text.lock.inode 0.0086
3 wait_for_tcp_connect 0.0054
3 tcp_v4_get_port 0.0045
3 tcp_put_port 0.0150
3 tcp_init_xmit_timers 0.0221
3 tcp_clear_xmit_timers 0.0234
3 tcp_add_reno_sack 0.0357
3 sys_sched_getscheduler 0.0288
3 sys_fcntl64 0.0221
3 sys_accept 0.0119
3 sock_ioctl 0.0268
3 sock_fasync 0.0038
3 sock_def_error_report 0.0312
3 rt_check_expire__thr 0.0077
3 rh_init_int_timer 0.0278
3 reset_hc 0.0167
3 register_gifconf 0.0938
3 read_chan 0.0016
3 put_unused_buffer_head 0.0833
3 pipe_ioctl 0.0375
3 permission 0.0227
3 open_namei 0.0024
3 mm_release 0.0833
3 locks_remove_flock 0.0163
3 ksoftirqd 0.0153
3 journal_file_buffer 0.0682
3 iput 0.0060
3 ip_build_and_send_pkt 0.0067
3 interruptible_sleep_on 0.0250
3 inet_sock_destruct 0.0080
3 inet_ioctl 0.0079
3 inet_create 0.0048
3 immediate_bh 0.1071
3 get_unused_fd 0.0077
3 get_empty_inode 0.0179
3 flush_tlb_all_ipi 0.0395
3 filemap_fdatawait 0.0214
3 fd_install 0.0441
3 ext3_prepare_write 0.0056
3 ext3_mark_iloc_dirty 0.0357
3 e1000_watchdog 0.0064
3 e1000_read_phy_reg 0.0179
3 d_invalidate 0.0214
3 create_buffers 0.0125
3 cp_new_stat64 0.0095
3 copy_mm 0.0040
3 copy_files 0.0043
3 bdget 0.0078
3 __insert_into_lru_list 0.0300
3 __global_restore_flags 0.0417
3 __get_user_4 0.1250
2 write_ldt 0.0037
2 walk_page_buffers 0.0161
2 tcp_try_undo_partial 0.0093
2 tcp_try_undo_dsack 0.0294
2 tcp_send_ack 0.0100
2 tcp_retransmit_skb 0.0034
2 tcp_new 0.0333
2 tcp_init_metrics 0.0063
2 tcp_fragment 0.0029
2 tcp_fixup_sndbuf 0.0455
2 tcp_enter_loss 0.0051
2 tcp_destroy_sock 0.0043
2 tcp_close_state 0.0104
2 tcp_child_process 0.0134
2 tcp_bucket_create 0.0263
2 tasklet_init 0.0500
2 sys_close 0.0179
2 sock_recvmsg 0.0116
2 sock_map_fd 0.0052
2 sk_free 0.0172
2 sk_alloc 0.0208
2 sem_exit 0.0038
2 reschedule 0.1667
2 put_files_struct 0.0109
2 path_release 0.0417
2 path_lookup 0.0556
2 mmput 0.0172
2 kiobuf_init 0.0238
2 journal_unfile_buffer 0.0556
2 journal_get_undo_access 0.0070
2 journal_dirty_data 0.0047
2 ip_mc_drop_socket 0.0156
2 idedisk_open 0.0156
2 grow_dev_page 0.0122
2 getname 0.0128
2 generic_unplug_device 0.0333
2 generic_file_llseek 0.0135
2 free_kiovec 0.0200
2 flush_signal_handlers 0.0333
2 filemap_nopage 0.0040
2 ext3_writepage_trans_blocks 0.0152
2 ext3_getblk 0.0030
2 do_generic_file_read 0.0017
2 destroy_inode 0.0455
2 deliver_to_old_ones 0.0114
2 copy_namespace 0.0023
2 clear_inode 0.0122
2 clean_inode 0.0109
2 block_prepare_write 0.0179
2 alloc_kiovec 0.0161
2 add_page_to_hash_queue 0.0455
2 activate_page 0.0139
2 __tcp_v4_lookup_listener 0.0208
2 __journal_refile_buffer 0.0088
2 __generic_copy_from_user 0.0227
2 __find_lock_page 0.0500
2 __down_trylock 0.0263
2 __down_failed_trylock 0.1667
2 __block_commit_write 0.0098
2 .text.lock.sched 0.0042
1 vt_console_device 0.0250
1 vgacon_save_screen 0.0114
1 udp_sendmsg 0.0010
1 tty_write 0.0015
1 tty_ioctl 0.0011
1 tcp_xmit_retransmit_queue 0.0010
1 tcp_xmit_probe_skb 0.0086
1 tcp_v4_synq_add 0.0063
1 tcp_v4_rebuild_header 0.0028
1 tcp_timewait_kill 0.0045
1 tcp_sync_mss 0.0081
1 tcp_reset_keepalive_timer 0.0250
1 tcp_reset 0.0039
1 tcp_recv_urg 0.0044
1 tcp_incr_quickack 0.0167
1 tcp_error 0.0139
1 sys_time 0.0119
1 sys_stat64 0.0086
1 sys_modify_ldt 0.0106
1 sys_lstat64 0.0089
1 sys_llseek 0.0034
1 sys_getppid 0.0250
1 sys_getpeername 0.0081
1 sys_fstat64 0.0104
1 sys_clone 0.0250
1 sys_brk 0.0042
1 sys_access 0.0034
1 svc_udp_recvfrom 0.0014
1 sock_wmalloc 0.0125
1 sock_release 0.0104
1 sock_read 0.0064
1 sock_create 0.0036
1 skb_recv_datagram 0.0042
1 show_mem 0.0033
1 setup_rt_frame 0.0015
1 setscheduler 0.0024
1 secure_tcp_sequence_number 0.0051
1 restart_request 0.0132
1 remove_inode_page 0.0192
1 remove_expectations 0.0208
1 proc_pid_lookup 0.0020
1 proc_lookup 0.0068
1 pdc202xx_reset 0.0074
1 path_walk 0.0357
1 opost 0.0023
1 old_mmap 0.0033
1 normal_poll 0.0035
1 nfs3svc_encode_attrstat 0.0020
1 n_tty_receive_buf 0.0002
1 move_addr_to_user 0.0119
1 mm_init 0.0051
1 memory_open 0.0050
1 kmem_cache_grow 0.0018
1 kill_fasync 0.0172
1 journal_free_journal_head 0.0500
1 journal_bmap 0.0089
1 journal_blocks_per_page 0.0312
1 journal_alloc_journal_head 0.0096
1 is_read_only 0.0147
1 ip_ct_gather_frags 0.0031
1 init_private_file 0.0093
1 init_once 0.0038
1 init_buffer_head 0.0182
1 inet_release 0.0125
1 inet_getname 0.0083
1 inet_autobind 0.0023
1 get_pipe_inode 0.0057
1 free_pgtables 0.0071
1 fn_hash_lookup 0.0045
1 find_inlist_lock 0.0035
1 file_move 0.0139
1 fcntl_dirnotify 0.0032
1 ext3_write_inode 0.0192
1 ext3_test_allocatable 0.0156
1 ext3_release_file 0.0357
1 ext3_read_inode 0.0014
1 ext3_open_file 0.0250
1 ext3_group_sparse 0.0104
1 ext3_file_write 0.0053
1 exit_sighand 0.0100
1 e1000_tbi_adjust_stats 0.0021
1 e1000_check_for_link 0.0020
1 do_timer 0.0125
1 do_tcp_sendpages 0.0004
1 do_sys_settimeofday 0.0064
1 do_readv_writev 0.0016
1 do_pollfd 0.0074
1 death_by_timeout 0.0068
1 d_instantiate 0.0139
1 cpu_raise_softirq 0.0154
1 copy_thread 0.0071
1 clear_page_tables 0.0046
1 clean_from_lists 0.0139
1 check_unthrottle 0.0208
1 change_protection 0.0027
1 cached_lookup 0.0119
1 add_to_page_cache_locked 0.0081
1 __user_walk 0.0156
1 __remove_inode_page 0.0104
1 __remove_from_lru_list 0.0119
1 __refile_buffer 0.0109
1 __rb_rotate_right 0.0156
1 __loop_delay 0.0250
1 .text.lock.super 0.0071
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 11:06 ` [RESEND] " Roy Sigurd Karlsbakk
@ 2002-10-23 13:01 ` bert hubert
2002-10-23 13:21 ` David S. Miller
` (2 more replies)
2002-10-23 18:01 ` [RESEND] tuning linux for high network performance? Denis Vlasenko
1 sibling, 3 replies; 39+ messages in thread
From: bert hubert @ 2002-10-23 13:01 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: netdev, Kernel mailing list
On Wed, Oct 23, 2002 at 01:06:18PM +0200, Roy Sigurd Karlsbakk wrote:
> > I've got this video server serving video for VoD. problem is the P4 1.8
> > seems to be maxed out by a few system calls. The below output is for ~50
> > clients streaming at ~4.5Mbps. if trying to increase this to ~70, the CPU
> > maxes out.
'50 clients *each* streaming at ~4.4MBps', better make that clear, otherwise
something is *very* broken. Also mention that you have an e1000 card which
does not do outgoing checksumming.
You'd think that a kernel would be able to do 250megabits of TCP checksums
though.
> ...adding the whole profile output - sorted by the first column this time...
>
> 905182 total 0.4741
> 121426 csum_partial_copy_generic 474.3203
> 93633 default_idle 1800.6346
> 74665 do_wp_page 111.1086
Perhaps the 'copy' also entails grabbing the page from disk, leading to
inflated csum_partial_copy_generic stats?
Where are you serving from?
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 13:01 ` bert hubert
@ 2002-10-23 13:21 ` David S. Miller
2002-10-23 13:42 ` Roy Sigurd Karlsbakk
2002-10-23 13:41 ` [RESEND] tuning linux for high network performance? Roy Sigurd Karlsbakk
2002-10-23 14:59 ` Nivedita Singhvi
2 siblings, 1 reply; 39+ messages in thread
From: David S. Miller @ 2002-10-23 13:21 UTC (permalink / raw)
To: bert hubert; +Cc: Roy Sigurd Karlsbakk, netdev, Kernel mailing list
On Wed, 2002-10-23 at 06:01, bert hubert wrote:
> Also mention that you have an e1000 card which
> does not do outgoing checksumming.
The e1000 can very well do hardware checksumming on transmit.
The missing piece of the puzzle is that his application is not
using sendfile(), without which no transmit checksum offload
can take place.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 18:01 ` [RESEND] tuning linux for high network performance? Denis Vlasenko
@ 2002-10-23 13:36 ` Roy Sigurd Karlsbakk
2002-10-24 16:22 ` Denis Vlasenko
2002-10-23 14:52 ` [RESEND] tuning linux for high network performance? Nivedita Singhvi
1 sibling, 1 reply; 39+ messages in thread
From: Roy Sigurd Karlsbakk @ 2002-10-23 13:36 UTC (permalink / raw)
To: vda, netdev; +Cc: Kernel mailing list
> >
> > 905182 total 0.4741
> > 121426 csum_partial_copy_generic 474.3203
>
> Well, maybe take a look at this func and try to optimize it?
I don't know assembly that good - sorry.
> > 93633 default_idle 1800.6346
> > 74665 do_wp_page 111.1086
>
> What's this?
do_wp_page is Defined as a function in: mm/memory.c
comments from the file:
/*
* This routine handles present pages, when users try to write
* to a shared page. It is done by copying the page to a new address
* and decrementing the shared-page counter for the old page.
*
* Goto-purists beware: the only reason for goto's here is that it results
* in better assembly code.. The "default" path will see no jumps at all.
*
* Note that this routine assumes that the protection checks have been
* done by the caller (the low-level page fault routine in most cases).
* Thus we can safely just mark it writable once we've done any necessary
* COW.
*
* We also mark the page dirty at this point even though the page will
* change only once the write actually happens. This avoids a few races,
* and potentially makes it more efficient.
*
* We hold the mm semaphore and the page_table_lock on entry and exit
* with the page_table_lock released.
*/
>
> > 65857 ide_intr 184.9916
>
> You have 1 ide_intr per 2 csum_partial_copy_generic... hmmm...
> how large is your readahead? I assume you'd like to fetch
> more sectors from ide per interrupt. (I hope you do DMA ;)
doing DMA - RAID-0 with 1MB chunk size on 4 disks.
> > 53636 handle_IRQ_event 432.5484
> > 21973 do_softirq 107.7108
> > 20498 e1000_intr 244.0238
>
> I know zero about networking, but why 120 000 csum_partial_copy_generic
> and inly 20 000 nic interrupts? That may be abnormal.
sorry
I don't know
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 13:01 ` bert hubert
2002-10-23 13:21 ` David S. Miller
@ 2002-10-23 13:41 ` Roy Sigurd Karlsbakk
2002-10-23 14:59 ` Nivedita Singhvi
2 siblings, 0 replies; 39+ messages in thread
From: Roy Sigurd Karlsbakk @ 2002-10-23 13:41 UTC (permalink / raw)
To: bert hubert; +Cc: netdev, Kernel mailing list
> '50 clients *each* streaming at ~4.4MBps', better make that clear,
> otherwise something is *very* broken. Also mention that you have an e1000
> card which does not do outgoing checksumming.
just to clearify
s/MBps/Mbps/
s/bps/bits per second/
> You'd think that a kernel would be able to do 250megabits of TCP checksums
> though.
>
> > ...adding the whole profile output - sorted by the first column this
> > time...
> >
> > 905182 total 0.4741
> > 121426 csum_partial_copy_generic 474.3203
> > 93633 default_idle 1800.6346
> > 74665 do_wp_page 111.1086
>
> Perhaps the 'copy' also entails grabbing the page from disk, leading to
> inflated csum_partial_copy_generic stats?
I really don't know. Just to clearify a little more - the server app uses
O_DIRECT to read the data before tossing it to the socket.
> Where are you serving from?
What do you mean?
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 13:21 ` David S. Miller
@ 2002-10-23 13:42 ` Roy Sigurd Karlsbakk
2002-10-23 17:01 ` bert hubert
2002-10-24 4:11 ` David S. Miller
0 siblings, 2 replies; 39+ messages in thread
From: Roy Sigurd Karlsbakk @ 2002-10-23 13:42 UTC (permalink / raw)
To: David S. Miller, bert hubert; +Cc: netdev, Kernel mailing list
> The e1000 can very well do hardware checksumming on transmit.
>
> The missing piece of the puzzle is that his application is not
> using sendfile(), without which no transmit checksum offload
> can take place.
As far as I've understood, sendfile() won't do much good with large files. Is
this right?
We're talking of 3-6GB files here ...
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 18:01 ` [RESEND] tuning linux for high network performance? Denis Vlasenko
2002-10-23 13:36 ` Roy Sigurd Karlsbakk
@ 2002-10-23 14:52 ` Nivedita Singhvi
1 sibling, 0 replies; 39+ messages in thread
From: Nivedita Singhvi @ 2002-10-23 14:52 UTC (permalink / raw)
To: vda; +Cc: Roy Sigurd Karlsbakk, netdev
Denis Vlasenko wrote:
> I know zero about networking, but why 120 000 csum_partial_copy_generic
> and inly 20 000 nic interrupts? That may be abnormal.
> --
> vda
Because firstly, we pick up several packets per interrupt,
and additionally, the function is also called on the send side.
thanks,
Nivedita
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 13:01 ` bert hubert
2002-10-23 13:21 ` David S. Miller
2002-10-23 13:41 ` [RESEND] tuning linux for high network performance? Roy Sigurd Karlsbakk
@ 2002-10-23 14:59 ` Nivedita Singhvi
2002-10-23 15:26 ` O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?) Roy Sigurd Karlsbakk
2 siblings, 1 reply; 39+ messages in thread
From: Nivedita Singhvi @ 2002-10-23 14:59 UTC (permalink / raw)
To: bert hubert; +Cc: Roy Sigurd Karlsbakk, netdev, Kernel mailing list
bert hubert wrote:
> > ...adding the whole profile output - sorted by the first column this time...
> >
> > 905182 total 0.4741
> > 121426 csum_partial_copy_generic 474.3203
> > 93633 default_idle 1800.6346
> > 74665 do_wp_page 111.1086
>
> Perhaps the 'copy' also entails grabbing the page from disk, leading to
> inflated csum_partial_copy_generic stats?
I think this is strictly a copy from user space->kernel and vice versa.
This shouldnt include the disk access etc.
thanks,
Nivedita
^ permalink raw reply [flat|nested] 39+ messages in thread
* O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?)
2002-10-23 14:59 ` Nivedita Singhvi
@ 2002-10-23 15:26 ` Roy Sigurd Karlsbakk
2002-10-23 16:34 ` Nivedita Singhvi
0 siblings, 1 reply; 39+ messages in thread
From: Roy Sigurd Karlsbakk @ 2002-10-23 15:26 UTC (permalink / raw)
To: Nivedita Singhvi, bert hubert; +Cc: netdev, Kernel mailing list
On Wednesday 23 October 2002 16:59, Nivedita Singhvi wrote:
> bert hubert wrote:
> > > ...adding the whole profile output - sorted by the first column this
> > > time...
> > >
> > > 905182 total 0.4741
> > > 121426 csum_partial_copy_generic 474.3203
> > > 93633 default_idle 1800.6346
> > > 74665 do_wp_page 111.1086
> >
> > Perhaps the 'copy' also entails grabbing the page from disk, leading to
> > inflated csum_partial_copy_generic stats?
>
> I think this is strictly a copy from user space->kernel and vice versa.
> This shouldnt include the disk access etc.
hm
I'm doing O_DIRECT read (from disk), so it needs to be user -> kernel, then.
any chance of using O_DIRECT to the socket?
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?)
2002-10-23 15:26 ` O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?) Roy Sigurd Karlsbakk
@ 2002-10-23 16:34 ` Nivedita Singhvi
0 siblings, 0 replies; 39+ messages in thread
From: Nivedita Singhvi @ 2002-10-23 16:34 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: bert hubert, netdev, Kernel mailing list
Roy Sigurd Karlsbakk wrote:
> I'm doing O_DIRECT read (from disk), so it needs to be user -> kernel, then.
>
> any chance of using O_DIRECT to the socket?
Hmm, I'm still not clear on why you cannot use sendfile()?
I was not aware of any upper limit to the file size in order
for sendfile() to be used? From what little I know, this
is exactly the kind of situation that sendfile was intended
to benefit.
thanks,
Nivedita
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?)
@ 2002-10-23 16:34 ` Nivedita Singhvi
0 siblings, 0 replies; 39+ messages in thread
From: Nivedita Singhvi @ 2002-10-23 16:34 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: bert hubert, netdev, Kernel mailing list
Roy Sigurd Karlsbakk wrote:
> I'm doing O_DIRECT read (from disk), so it needs to be user -> kernel, then.
>
> any chance of using O_DIRECT to the socket?
Hmm, I'm still not clear on why you cannot use sendfile()?
I was not aware of any upper limit to the file size in order
for sendfile() to be used? From what little I know, this
is exactly the kind of situation that sendfile was intended
to benefit.
thanks,
Nivedita
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 13:42 ` Roy Sigurd Karlsbakk
@ 2002-10-23 17:01 ` bert hubert
2002-10-23 17:10 ` Ben Greear
` (2 more replies)
2002-10-24 4:11 ` David S. Miller
1 sibling, 3 replies; 39+ messages in thread
From: bert hubert @ 2002-10-23 17:01 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: David S. Miller, netdev, Kernel mailing list
On Wed, Oct 23, 2002 at 03:42:48PM +0200, Roy Sigurd Karlsbakk wrote:
> > The e1000 can very well do hardware checksumming on transmit.
> >
> > The missing piece of the puzzle is that his application is not
> > using sendfile(), without which no transmit checksum offload
> > can take place.
>
> As far as I've understood, sendfile() won't do much good with large files. Is
> this right?
I still refuse to believe that a 1.8GHz Pentium4 can only checksum
250megabits/second. MD Raid5 does better and they probably don't use a
checksum as braindead as that used by TCP.
If the checksumming is not the problem, the copying is, which would be a
weakness of your hardware. The function profiled does both the copying and
the checksumming.
But 250megabits/second also seems low.
Dave?
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 17:01 ` bert hubert
@ 2002-10-23 17:10 ` Ben Greear
2002-10-23 17:11 ` Richard B. Johnson
2002-10-23 17:12 ` Nivedita Singhvi
2 siblings, 0 replies; 39+ messages in thread
From: Ben Greear @ 2002-10-23 17:10 UTC (permalink / raw)
To: bert hubert
Cc: Roy Sigurd Karlsbakk, David S. Miller, netdev, Kernel mailing list
bert hubert wrote:
> I still refuse to believe that a 1.8GHz Pentium4 can only checksum
> 250megabits/second. MD Raid5 does better and they probably don't use a
> checksum as braindead as that used by TCP.
For what it's worth, I have been able to send and receive 400+ Mbps
of traffic, by directional, on the same machine (ie, about 1600 Mbps
of payload across the PCI bus)
So, it's probably not the e1000 or networking code that is slowing you down.
(This was on a 64/66 PCI, Dual-AMD 2Ghz machine though,
are you running only 32/33 PCI? If not, where did you find this motherboard!)
Have you tried just reading the information from disk and doing everying except
the final 'send/write/sendto' ? That would help determine if it is your
file reads that are killing you.
Ben
--
Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 17:01 ` bert hubert
2002-10-23 17:10 ` Ben Greear
@ 2002-10-23 17:11 ` Richard B. Johnson
2002-10-23 17:12 ` Nivedita Singhvi
2 siblings, 0 replies; 39+ messages in thread
From: Richard B. Johnson @ 2002-10-23 17:11 UTC (permalink / raw)
To: bert hubert
Cc: Roy Sigurd Karlsbakk, David S. Miller, netdev, Kernel mailing list
On Wed, 23 Oct 2002, bert hubert wrote:
> On Wed, Oct 23, 2002 at 03:42:48PM +0200, Roy Sigurd Karlsbakk wrote:
> > > The e1000 can very well do hardware checksumming on transmit.
> > >
> > > The missing piece of the puzzle is that his application is not
> > > using sendfile(), without which no transmit checksum offload
> > > can take place.
> >
> > As far as I've understood, sendfile() won't do much good with large files. Is
> > this right?
>
> I still refuse to believe that a 1.8GHz Pentium4 can only checksum
> 250megabits/second. MD Raid5 does better and they probably don't use a
> checksum as braindead as that used by TCP.
>
> If the checksumming is not the problem, the copying is, which would be a
> weakness of your hardware. The function profiled does both the copying and
> the checksumming.
>
> But 250megabits/second also seems low.
>
> Dave?
>
Ordinary DUAL Pentium 400 MHz machine does this...
Calculating CPU speed...done
Testing checksum speed...done
Testing RAM copy...done
Testing I/O port speed...done
CPU Clock = 400 MHz
checksum speed = 685 Mb/s
RAM copy = 1549 Mb/s
I/O port speed = 654 kb/s
This is 685 megaBYTES per second.
checksum speed = 685 Mb/s
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 17:01 ` bert hubert
2002-10-23 17:10 ` Ben Greear
2002-10-23 17:11 ` Richard B. Johnson
@ 2002-10-23 17:12 ` Nivedita Singhvi
2002-10-23 17:56 ` Richard B. Johnson
2 siblings, 1 reply; 39+ messages in thread
From: Nivedita Singhvi @ 2002-10-23 17:12 UTC (permalink / raw)
To: bert hubert
Cc: Roy Sigurd Karlsbakk, David S. Miller, netdev, Kernel mailing list
bert hubert wrote:
> I still refuse to believe that a 1.8GHz Pentium4 can only checksum
> 250megabits/second. MD Raid5 does better and they probably don't use a
> checksum as braindead as that used by TCP.
>
> If the checksumming is not the problem, the copying is, which would be a
> weakness of your hardware. The function profiled does both the copying and
> the checksumming.
Yep, its not so much the checksumming as the fact that this is
done over each byte of data and copied.
thanks,
Nivedita
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 17:12 ` Nivedita Singhvi
@ 2002-10-23 17:56 ` Richard B. Johnson
2002-10-23 18:07 ` Nivedita Singhvi
0 siblings, 1 reply; 39+ messages in thread
From: Richard B. Johnson @ 2002-10-23 17:56 UTC (permalink / raw)
To: Nivedita Singhvi
Cc: bert hubert, Roy Sigurd Karlsbakk, David S. Miller, netdev,
Kernel mailing list
On Wed, 23 Oct 2002, Nivedita Singhvi wrote:
> bert hubert wrote:
>
> > I still refuse to believe that a 1.8GHz Pentium4 can only checksum
> > 250megabits/second. MD Raid5 does better and they probably don't use a
> > checksum as braindead as that used by TCP.
> >
> > If the checksumming is not the problem, the copying is, which would be a
> > weakness of your hardware. The function profiled does both the copying and
> > the checksumming.
>
> Yep, its not so much the checksumming as the fact that this is
> done over each byte of data and copied.
>
> thanks,
> Nivedita
No. It's done over each word (short int) and the actual summation
takes place during the address calculation of the next word. This
gets you a checksum that is practically free.
A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second.
It will copy at 1,549 megabytes per second. Those are megaBYTES!
If you have slow network performance it has nothing to do with
either copy or checksum. Data transmission acts like a low-pass
filter. The dominant pole of that transfer function determines
the speed, that's why it's called dominant. If you measure
a data-rate of 10 megabytes/second. Nothing you do with copy
or checksum will affect it to any significant extent.
If you have a data-rate of 100 megabytes per second, then any
tinkering with copy will have an effective improvement ratio
of 100/1,559 ~= 0.064. If you have a data rate of 100 megabytes
per second and you tinker with checksum, you get an improvement
ratio of 100/685 ~=0.14. These are just not the things that are
affecting your performance.
If you were to double the checksumming speed, you increase the
throughput by 2 * 0.14 = 0.28 with the parameters shown.
The TCP/IP checksum is quite nice. It may have been discovered
by accident, but it's still nice. It works regardless of whether
you have a little endian or big endian machine. It also doesn't
wrap so you don't (usually) show a good checksum when the data
is bad. It does have the characteristic that if all the bits are
inverted, it will checksum good. However, there are not too many
real-world scenarios that would result in this inversion. So it's
not "brain-dead" as you state. A hardware checksum is really
quick because it's really easy.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 11:06 ` [RESEND] " Roy Sigurd Karlsbakk
2002-10-23 13:01 ` bert hubert
@ 2002-10-23 18:01 ` Denis Vlasenko
2002-10-23 13:36 ` Roy Sigurd Karlsbakk
2002-10-23 14:52 ` [RESEND] tuning linux for high network performance? Nivedita Singhvi
1 sibling, 2 replies; 39+ messages in thread
From: Denis Vlasenko @ 2002-10-23 18:01 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk, netdev
On 23 October 2002 09:06, Roy Sigurd Karlsbakk wrote:
> > I've got this video server serving video for VoD. problem is the P4
> > 1.8 seems to be maxed out by a few system calls. The below output
> > is for ~50 clients streaming at ~4.5Mbps. if trying to increase
> > this to ~70, the CPU maxes out.
> >
> > Does anyone have an idea?
>
> ...adding the whole profile output - sorted by the first column this
> time...
>
> 905182 total 0.4741
> 121426 csum_partial_copy_generic 474.3203
Well, maybe take a look at this func and try to optimize it?
> 93633 default_idle 1800.6346
> 74665 do_wp_page 111.1086
What's this?
> 65857 ide_intr 184.9916
You have 1 ide_intr per 2 csum_partial_copy_generic... hmmm...
how large is your readahead? I assume you'd like to fetch
more sectors from ide per interrupt. (I hope you do DMA ;)
> 53636 handle_IRQ_event 432.5484
> 21973 do_softirq 107.7108
> 20498 e1000_intr 244.0238
I know zero about networking, but why 120 000 csum_partial_copy_generic
and inly 20 000 nic interrupts? That may be abnormal.
--
vda
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 17:56 ` Richard B. Johnson
@ 2002-10-23 18:07 ` Nivedita Singhvi
2002-10-23 18:30 ` Richard B. Johnson
0 siblings, 1 reply; 39+ messages in thread
From: Nivedita Singhvi @ 2002-10-23 18:07 UTC (permalink / raw)
To: root
Cc: bert hubert, Roy Sigurd Karlsbakk, David S. Miller, netdev,
Kernel mailing list
"Richard B. Johnson" wrote:
> No. It's done over each word (short int) and the actual summation
> takes place during the address calculation of the next word. This
> gets you a checksum that is practically free.
Yep, sorry, word, not byte. My bad. The cost is in the fact
that this whole process involves loading each word of the data
stream into a register. Which is why I also used to consider
the checksum cost as negligible.
> A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second.
> It will copy at 1,549 megabytes per second. Those are megaBYTES!
But then why the difference in the checksum/copy and copy?
Are you saying the checksum is not costing you 864 megabytes
a second??
thanks,
Nivedita
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 18:07 ` Nivedita Singhvi
@ 2002-10-23 18:30 ` Richard B. Johnson
0 siblings, 0 replies; 39+ messages in thread
From: Richard B. Johnson @ 2002-10-23 18:30 UTC (permalink / raw)
To: Nivedita Singhvi
Cc: bert hubert, Roy Sigurd Karlsbakk, David S. Miller, netdev,
Kernel mailing list
On Wed, 23 Oct 2002, Nivedita Singhvi wrote:
> "Richard B. Johnson" wrote:
>
> > No. It's done over each word (short int) and the actual summation
> > takes place during the address calculation of the next word. This
> > gets you a checksum that is practically free.
>
> Yep, sorry, word, not byte. My bad. The cost is in the fact
> that this whole process involves loading each word of the data
> stream into a register. Which is why I also used to consider
> the checksum cost as negligible.
>
> > A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second.
> > It will copy at 1,549 megabytes per second. Those are megaBYTES!
>
> But then why the difference in the checksum/copy and copy?
> Are you saying the checksum is not costing you 864 megabytes
> a second??
Costing you 864 megabytes per second?
Lets say the checksum was free. You are then able to INF bytes/per/sec.
So it's costing you INF bytes/per/sec? No, it's costing you nothing.
If we were not dealing with INF, then 'Cost' is approximately 1/N, not
N. Cost is work_done_without_checksum - work_done_with_checksum. Because
of the low-pass filter pole, these numbers are practically the same.
But, you can get a measurable difference between any two large numbers.
This makes the 'cost' seem high. You need to make it relative to make
any sense, so a 'goodness' can be expressed as a ratio of the cost and
the work having been done.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 13:42 ` Roy Sigurd Karlsbakk
2002-10-23 17:01 ` bert hubert
@ 2002-10-24 4:11 ` David S. Miller
2002-10-24 9:37 ` Karen Shaeffer
2002-10-24 10:30 ` sendfile64() anyone? (was [RESEND] tuning linux for high network performance?) Roy Sigurd Karlsbakk
1 sibling, 2 replies; 39+ messages in thread
From: David S. Miller @ 2002-10-24 4:11 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: bert hubert, netdev, Kernel mailing list
On Wed, 2002-10-23 at 06:42, Roy Sigurd Karlsbakk wrote:
> As far as I've understood, sendfile() won't do much good with large files. Is
> this right?
There is always a benefit to using sendfile(), when you use
sendfile() the cpu doesn't touch one byte of the data if
the network card support TX checksumming. The disk DMAs
to ram, then the net card DMAs from ram. Simple as that.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-24 4:11 ` David S. Miller
@ 2002-10-24 9:37 ` Karen Shaeffer
2002-10-24 10:30 ` sendfile64() anyone? (was [RESEND] tuning linux for high network performance?) Roy Sigurd Karlsbakk
1 sibling, 0 replies; 39+ messages in thread
From: Karen Shaeffer @ 2002-10-24 9:37 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
On Wed, Oct 23, 2002 at 09:11:09PM -0700, David S. Miller wrote:
> On Wed, 2002-10-23 at 06:42, Roy Sigurd Karlsbakk wrote:
> > As far as I've understood, sendfile() won't do much good with large files. Is
> > this right?
>
> There is always a benefit to using sendfile(), when you use
> sendfile() the cpu doesn't touch one byte of the data if
> the network card support TX checksumming. The disk DMAs
> to ram, then the net card DMAs from ram. Simple as that.
Referring to:
$ rpm -qf /usr/include/sys/sendfile.h
glibc-devel-2.2.5-40
quoting "sendfile.h"
#ifdef __USE_FILE_OFFSET64
# error "<sys/sendfile.h> cannot be used with _FILE_OFFSET_BITS=64"
#endif
So, how does one use sendfile() for large files that are greater than 2
GBytes? Am I missing something?
Thanks,
Karen
--
Karen Shaeffer
Neuralscape; Santa Cruz, Ca. 95060
shaeffer@neuralscape.com http://www.neuralscape.com
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?)
2002-10-23 16:34 ` Nivedita Singhvi
(?)
@ 2002-10-24 10:14 ` Roy Sigurd Karlsbakk
2002-10-24 10:46 ` David S. Miller
-1 siblings, 1 reply; 39+ messages in thread
From: Roy Sigurd Karlsbakk @ 2002-10-24 10:14 UTC (permalink / raw)
To: Nivedita Singhvi; +Cc: bert hubert, netdev, Kernel mailing list
> Hmm, I'm still not clear on why you cannot use sendfile()?
> I was not aware of any upper limit to the file size in order
> for sendfile() to be used? From what little I know, this
> is exactly the kind of situation that sendfile was intended
> to benefit.
I can't use sendfile(). I'm working with files > 4GB, and from man 2 sendfile:
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
int main() {
ssize_t s1;
off_t offset;
size_t count;
printf("sizeof ssize_t: %d\n", sizeof s1);
printf("sizeof size_t: %d\n", sizeof count);
printf("sizeof off_t: %d\n", sizeof offset);
return 0;
}
running it
$ ./sendfile_test
sizeof ssize_t: 4
sizeof size_t: 4
sizeof off_t: 4
$
as far as I'm concerned, this will not allow me to address files past the 4GB
limit (or was it 2?)
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [flat|nested] 39+ messages in thread
* sendfile64() anyone? (was [RESEND] tuning linux for high network performance?)
2002-10-24 4:11 ` David S. Miller
2002-10-24 9:37 ` Karen Shaeffer
@ 2002-10-24 10:30 ` Roy Sigurd Karlsbakk
2002-10-24 10:47 ` David S. Miller
1 sibling, 1 reply; 39+ messages in thread
From: Roy Sigurd Karlsbakk @ 2002-10-24 10:30 UTC (permalink / raw)
To: David S. Miller; +Cc: bert hubert, netdev, Kernel mailing list
On Thursday 24 October 2002 06:11, David S. Miller wrote:
> On Wed, 2002-10-23 at 06:42, Roy Sigurd Karlsbakk wrote:
> > As far as I've understood, sendfile() won't do much good with large
> > files. Is this right?
>
> There is always a benefit to using sendfile(), when you use
> sendfile() the cpu doesn't touch one byte of the data if
> the network card support TX checksumming. The disk DMAs
> to ram, then the net card DMAs from ram. Simple as that.
Are there any plans of implementing sendfile64() or sendfile() support for
-D_FILE_OFFSET_BITS=64?
(from man 2 sendfile)
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
int main() {
ssize_t s1;
size_t count;
off_t offset;
printf("sizeof ssize_t: %d\n", sizeof s1);
printf("sizeof size_t: %d\n", sizeof count);
printf("sizeof off_t: %d\n", sizeof offset);
return 0;
}
$ make
...
$ ./sendfile_test
sizeof ssize_t: 4
sizeof size_t: 4
sizeof off_t: 4
$
and - when attempting to build this with -D_FILE_OFFSET_BITS=64
[roy@roy-sin micro_httpd-O_DIRECT]$ make sendfile_test
gcc -D_DEBUG -Wall -W -D_GNU_SOURCE -D_NO_DIR_ACCESS -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -DUSE_O_DIRECT -DINETD -Wno-unused -O0 -ggdb -c
sendfile_test.c
In file included from sendfile_test.c:1:
/usr/include/sys/sendfile.h:26: #error "<sys/sendfile.h> cannot be used with
_FILE_OFFSET_BITS=64"
make: *** [sendfile_test.o] Error 1
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?)
2002-10-24 10:14 ` Roy Sigurd Karlsbakk
@ 2002-10-24 10:46 ` David S. Miller
0 siblings, 0 replies; 39+ messages in thread
From: David S. Miller @ 2002-10-24 10:46 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk
Cc: Nivedita Singhvi, bert hubert, netdev, Kernel mailing list
On Thu, 2002-10-24 at 03:14, Roy Sigurd Karlsbakk wrote:
> I can't use sendfile(). I'm working with files > 4GB, and from man 2 sendfile:
That's what sendfile64() is for. In fact every vendor I am aware
of is shipping the sys_sendfile64() patch in their kernels and
an appropriately fixed up glibc.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?)
@ 2002-10-24 10:46 ` David S. Miller
0 siblings, 0 replies; 39+ messages in thread
From: David S. Miller @ 2002-10-24 10:46 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk
Cc: Nivedita Singhvi, bert hubert, netdev, Kernel mailing list
On Thu, 2002-10-24 at 03:14, Roy Sigurd Karlsbakk wrote:
> I can't use sendfile(). I'm working with files > 4GB, and from man 2 sendfile:
That's what sendfile64() is for. In fact every vendor I am aware
of is shipping the sys_sendfile64() patch in their kernels and
an appropriately fixed up glibc.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: sendfile64() anyone? (was [RESEND] tuning linux for high network performance?)
2002-10-24 10:30 ` sendfile64() anyone? (was [RESEND] tuning linux for high network performance?) Roy Sigurd Karlsbakk
@ 2002-10-24 10:47 ` David S. Miller
2002-10-24 11:07 ` Roy Sigurd Karlsbakk
0 siblings, 1 reply; 39+ messages in thread
From: David S. Miller @ 2002-10-24 10:47 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: bert hubert, netdev, Kernel mailing list
On Thu, 2002-10-24 at 03:30, Roy Sigurd Karlsbakk wrote:
> Are there any plans of implementing sendfile64() or sendfile() support for
> -D_FILE_OFFSET_BITS=64?
This is old hat, and appears in every current vendor kernel I am
aware of and is in 2.5.x as well.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: sendfile64() anyone? (was [RESEND] tuning linux for high network performance?)
2002-10-24 10:47 ` David S. Miller
@ 2002-10-24 11:07 ` Roy Sigurd Karlsbakk
0 siblings, 0 replies; 39+ messages in thread
From: Roy Sigurd Karlsbakk @ 2002-10-24 11:07 UTC (permalink / raw)
To: David S. Miller; +Cc: bert hubert, netdev, Kernel mailing list
On Thursday 24 October 2002 12:47, David S. Miller wrote:
> On Thu, 2002-10-24 at 03:30, Roy Sigurd Karlsbakk wrote:
> > Are there any plans of implementing sendfile64() or sendfile() support
> > for -D_FILE_OFFSET_BITS=64?
>
> This is old hat, and appears in every current vendor kernel I am
> aware of and is in 2.5.x as well.
then where can I find these patches? I cannot use 2.5, and I usually try to
stick with an official kernel.
and - if this patch has been around all this time...
why isn't it in the official kernel yet?
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-24 16:22 ` Denis Vlasenko
@ 2002-10-24 11:50 ` Russell King
2002-10-24 12:42 ` bert hubert
2002-10-24 17:41 ` Denis Vlasenko
0 siblings, 2 replies; 39+ messages in thread
From: Russell King @ 2002-10-24 11:50 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: Roy Sigurd Karlsbakk, netdev, Kernel mailing list
On Thu, Oct 24, 2002 at 02:22:25PM -0200, Denis Vlasenko wrote:
> Please delete memory.o, rerun make bzImage, capture gcc
> command used for compiling memory.c, modify it:
>
> gcc ... -o memory.o -> gcc ... -S -o memory.s ...
Have you tried make mm/memory.s ?
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-24 11:50 ` Russell King
@ 2002-10-24 12:42 ` bert hubert
2002-10-24 17:41 ` Denis Vlasenko
1 sibling, 0 replies; 39+ messages in thread
From: bert hubert @ 2002-10-24 12:42 UTC (permalink / raw)
To: Denis Vlasenko, Roy Sigurd Karlsbakk, netdev
On Thu, Oct 24, 2002 at 12:50:31PM +0100, Russell King wrote:
> > gcc ... -o memory.o -> gcc ... -S -o memory.s ...
>
> Have you tried make mm/memory.s ?
or even make mm/memory.lst
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-23 13:36 ` Roy Sigurd Karlsbakk
@ 2002-10-24 16:22 ` Denis Vlasenko
2002-10-24 11:50 ` Russell King
0 siblings, 1 reply; 39+ messages in thread
From: Denis Vlasenko @ 2002-10-24 16:22 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk, netdev; +Cc: Kernel mailing list
On 23 October 2002 11:36, Roy Sigurd Karlsbakk wrote:
> > > 905182 total 0.4741
> > > 121426 csum_partial_copy_generic 474.3203
> >
> > Well, maybe take a look at this func and try to optimize it?
>
> I don't know assembly that good - sorry.
Well, I like it. Maybe I can look into it. Feel free
to bug me :-)
> > > 93633 default_idle 1800.6346
> > > 74665 do_wp_page 111.1086
> >
> > What's this?
>
> do_wp_page is Defined as a function in: mm/memory.c
>
> comments from the file:
> [snip]
Please delete memory.o, rerun make bzImage, capture gcc
command used for compiling memory.c, modify it:
gcc ... -o memory.o -> gcc ... -S -o memory.s ...
and examine assembler code. Maybe something will stick out
(or use objdump to disassemble memory.o, I recall nice
option to produce assembler output with C code intermixed
as comments!) (send disasmed listing to me offlist).
> > > 65857 ide_intr 184.9916
> >
> > You have 1 ide_intr per 2 csum_partial_copy_generic... hmmm...
> > how large is your readahead? I assume you'd like to fetch
> > more sectors from ide per interrupt. (I hope you do DMA ;)
>
> doing DMA - RAID-0 with 1MB chunk size on 4 disks.
You should aim at maxing out IDE performance.
Please find out how many sectors you read in one go.
Maybe:
# cat /proc/interrupts
# dd bs=1m count=1 if=/dev/hda of=/dev/null
# cat /proc/interrupts
and calculate how many IDE interrupts happened. (1mb = 2048 sectors)
--
vda
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RESEND] tuning linux for high network performance?
2002-10-24 11:50 ` Russell King
2002-10-24 12:42 ` bert hubert
@ 2002-10-24 17:41 ` Denis Vlasenko
2002-10-25 11:36 ` Csum and csum copyroutines benchmark Denis Vlasenko
1 sibling, 1 reply; 39+ messages in thread
From: Denis Vlasenko @ 2002-10-24 17:41 UTC (permalink / raw)
To: Russell King; +Cc: Roy Sigurd Karlsbakk, netdev, Kernel mailing list
On 24 October 2002 09:50, Russell King wrote:
> On Thu, Oct 24, 2002 at 02:22:25PM -0200, Denis Vlasenko wrote:
> > Please delete memory.o, rerun make bzImage, capture gcc
> > command used for compiling memory.c, modify it:
> >
> > gcc ... -o memory.o -> gcc ... -S -o memory.s ...
>
> Have you tried make mm/memory.s ?
No ;) but I have a feeling it will produce that file ;)))
I'm experimenting with different csum_ routines in userspace now.
--
vda
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Csum and csum copyroutines benchmark
2002-10-25 11:36 ` Csum and csum copyroutines benchmark Denis Vlasenko
@ 2002-10-25 7:48 ` Momchil Velikov
2002-10-25 13:59 ` Denis Vlasenko
2002-10-25 14:26 ` Daniel Egger
1 sibling, 1 reply; 39+ messages in thread
From: Momchil Velikov @ 2002-10-25 7:48 UTC (permalink / raw)
To: vda
Cc: Russell King, Roy Sigurd Karlsbakk, netdev, Kernel mailing list,
libc-alpha
>>>>> "Denis" == Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:
Denis> /me said:
>> I'm experimenting with different csum_ routines in userspace now.
Denis> Short conclusion:
Denis> 1. It is possible to speed up csum routines for AMD processors by 30%.
Denis> 2. It is possible to speed up csum_copy routines for both AMD and Intel
Denis> three times or more. Roy, do you like that? ;)
Additional data point:
Short summary:
1. Checksum - kernelpii_csum is ~19% faster
2. Copy - lernelpii_csum is ~6% faster
Dual Pentium III, 1266Mhz, 512K cache, 2G SDRAM (133Mhz, ECC)
The only changes I made were to decrease the buffer size to 1K (as I
think this is more representative to a network packet size, correct me
if I'm wrong) and increase the runs to 1024. Max values are worthless
indeed.
Csum benchmark program
buffer size: 1 K
Each test tried 1024 times, max and min CPU cycles are reported.
Please disregard max values. They are due to system interference only.
csum tests:
kernel_csum - took 941 max, 740 min cycles per kb. sum=0x44000077
kernel_csum - took 748 max, 742 min cycles per kb. sum=0x44000077
kernel_csum - took 60559 max, 742 min cycles per kb. sum=0x44000077
kernelpii_csum - took 52804 max, 601 min cycles per kb. sum=0x44000077
kernelpiipf_csum - took 12930 max, 601 min cycles per kb. sum=0x44000077
pfm_csum - took 10161 max, 1402 min cycles per kb. sum=0x44000077
pfm2_csum - took 864 max, 838 min cycles per kb. sum=0x44000077
copy tests:
kernel_copy - took 339 max, 239 min cycles per kb. sum=0x44000077
kernel_copy - took 239 max, 239 min cycles per kb. sum=0x44000077
kernel_copy - took 239 max, 239 min cycles per kb. sum=0x44000077
kernelpii_copy - took 244 max, 225 min cycles per kb. sum=0x44000077
ntqpf_copy - took 10867 max, 512 min cycles per kb. sum=0x44000077
ntqpfm_copy - took 710 max, 403 min cycles per kb. sum=0x44000077
ntq_copy - took 4535 max, 443 min cycles per kb. sum=0x44000077
ntqpf2_copy - took 563 max, 555 min cycles per kb. sum=0x44000077
Done
HOWEVER ...
sometimes (say 1/30) I get the following output:
Csum benchmark program
buffer size: 1 K
Each test tried 1024 times, max and min CPU cycles are reported.
Please disregard max values. They are due to system interference only.
csum tests:
kernel_csum - took 958 max, 740 min cycles per kb. sum=0x44000077
kernel_csum - took 748 max, 740 min cycles per kb. sum=0x44000077
kernel_csum - took 752 max, 740 min cycles per kb. sum=0x44000077
kernelpii_csum - took 624 max, 600 min cycles per kb. sum=0x44000077
kernelpiipf_csum - took 877211 max, 601 min cycles per kb. sum=0x44000077
Bad sum
Aborted
which is to say that pfm_csum and pfm2_csum results are not to be
trusted (at least on PIII (or my kernel CONFIG_MPENTIUMIII=y
config?)).
~velco
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Csum and csum copyroutines benchmark
2002-10-25 13:59 ` Denis Vlasenko
@ 2002-10-25 9:47 ` Momchil Velikov
2002-10-25 10:19 ` Alan Cox
1 sibling, 0 replies; 39+ messages in thread
From: Momchil Velikov @ 2002-10-25 9:47 UTC (permalink / raw)
To: vda; +Cc: Russell King, Roy Sigurd Karlsbakk, netdev, Kernel mailing list
[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]
>>>>> "Denis" == Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:
Denis> [please drop libc from CC:]
Denis> On 25 October 2002 05:48, Momchil Velikov wrote:
>>> Short conclusion:
>>> 1. It is possible to speed up csum routines for AMD processors
>>> by 30%.
>>> 2. It is possible to speed up csum_copy routines for both AMD
>>> andd Intel three times or more.
>> Additional data point:
>>
>> Short summary:
>> 1. Checksum - kernelpii_csum is ~19% faster
>> 2. Copy - lernelpii_csum is ~6% faster
>>
>> Dual Pentium III, 1266Mhz, 512K cache, 2G SDRAM (133Mhz, ECC)
>>
>> The only changes I made were to decrease the buffer size to 1K (as I
>> think this is more representative to a network packet size, correct
>> me if I'm wrong) and increase the runs to 1024. Max values are
>> worthless indeed.
Denis> Well, that makes it run entirely in L0 cache. This is unrealistic
Denis> for actual use. movntq is x3 faster when you hit RAM instead of L0.
Oops ...
Denis> You need to be more clever than that - generate pseudo-random
Denis> offsets in large buffer and run on ~1K pieces of that buffer.
Here it is:
Csum benchmark program
buffer size: 1 K
Each test tried 1024 times, max and min CPU cycles are reported.
Please disregard max values. They are due to system interference only.
csum tests:
kernel_csum - took 8678 max, 808 min cycles per kb. sum=0x400270e8
kernel_csum - took 941 max, 808 min cycles per kb. sum=0x400270e8
kernel_csum - took 11604 max, 808 min cycles per kb. sum=0x400270e8
kernelpii_csum - took 28839 max, 664 min cycles per kb. sum=0x400270e8
kernelpiipf_csum - took 9163 max, 665 min cycles per kb. sum=0x400270e8
pfm_csum - took 2788 max, 1470 min cycles per kb. sum=0x400270e8
pfm2_csum - took 1179 max, 915 min cycles per kb. sum=0x400270e8
copy tests:
kernel_copy - took 688 max, 263 min cycles per kb. sum=0x400270e8
kernel_copy - took 456 max, 263 min cycles per kb. sum=0x400270e8
kernel_copy - took 11241 max, 263 min cycles per kb. sum=0x400270e8
kernelpii_copy - took 7635 max, 246 min cycles per kb. sum=0x400270e8
ntqpf_copy - took 5349 max, 536 min cycles per kb. sum=0x400270e8
ntqpfm_copy - took 769 max, 425 min cycles per kb. sum=0x400270e8
ntq_copy - took 672 max, 469 min cycles per kb. sum=0x400270e8
ntqpf2_copy - took 8000 max, 579 min cycles per kb. sum=0x400270e8
Done
Ran on a 512K (my cache size) buffer, choosing each time a 1K
piece. (making the buffer larger (2M, 4M) does not make any
difference).
And the modified 0main.c is attached.
~velco
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0main.c --]
[-- Type: text/x-csrc, Size: 3996 bytes --]
#include <stdio.h>
#include <stdlib.h>
#define NAME(a) \
unsigned int a##csum(const unsigned char * buff, int len, \
unsigned int sum); \
unsigned int a##copy(const char *src, char *dst, \
int len, int sum, int *src_err_ptr, int *dst_err_ptr)
/* This makes adding/removing test functions easier */
/* asm ones... */
NAME(kernel_);
NAME(kernelpii_);
NAME(kernelpiipf_);
/* and C */
#include "pfm_csum.c"
#include "pfm2_csum.c"
#include "ntq_copy.c"
#include "ntqpf_copy.c"
#include "ntqpf2_copy.c"
#include "ntqpfm_copy.c"
const int TRY_TIMES = 1024;
const int NBUFS = 512;
const int BUFSIZE = 1024;
const int POISON = 0; // want to check correctness?
typedef unsigned int csum_func(const unsigned char * buff, int len,
unsigned int sum);
typedef unsigned int copy_func(const char *src, char *dst,
int len, int sum, int *src_err_ptr, int *dst_err_ptr);
static inline long long rdtsc()
{
unsigned int low,high;
__asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high));
return low + (((long long)high)<<32);
}
int die(const char *msg) {
puts(msg);
abort();
return 1;
}
unsigned test_one_csum(csum_func *func, char *name, char *buffer)
{
int i;
unsigned long long before,after,min,max;
unsigned sum;
// pick fastest run
min = ~0ULL;
max = 0;
for (i=0;i<TRY_TIMES;i++) {
before = rdtsc();
unsigned sum2 = func(buffer + (rand () % NBUFS) * BUFSIZE,
BUFSIZE, 0);
after = rdtsc();
if (before>after) die("timer overflow");
else {
after-=before;
if(min>after) min=after;
if(max<after) max=after;
}
}
printf("%32s - took %5lli max,%5lli min cycles per kb. sum=0x%08x\n",
name,
max / (BUFSIZE/1024),
min / (BUFSIZE/1024),
sum
);
}
unsigned test_one_copy(copy_func *func, char *name, char *buffer)
{
int i;
unsigned long long before,after,min,max;
unsigned sum;
int err;
// pick fastest run
min = ~0ULL;
max = 0;
for (i=0; i<TRY_TIMES; i++) {
if(POISON) memset(buffer, 0x55,BUFSIZE/2);
if(POISON) memset(buffer+BUFSIZE/2,0xaa,BUFSIZE/2);
buffer[0] = 0x77;
buffer[BUFSIZE/2-1] = 0x44;
before = rdtsc();
char *buf = buffer + rand () % (NBUFS - 1);
unsigned sum2 = func(buf,buf+BUFSIZE/2,BUFSIZE/2,0,&err,&err);
after = rdtsc();
if(POISON) if(memcmp(buffer,buffer+BUFSIZE/2,BUFSIZE/2)!=0) die("BAD copy!");
if (before>after) die("timer overflow");
else {
after-=before;
if(min>after) min=after;
if(max<after) max=after;
}
}
printf("%32s - took %5lli max,%5lli min cycles per kb. sum=0x%08x\n",
name,
max / (BUFSIZE/1024) / 2,
min / (BUFSIZE/1024) / 2,
sum
);
return sum;
}
void test_csum(char *buffer)
{
unsigned sum;
puts("csum tests:");
#define TEST_CSUM(a) test_one_csum(a,#a,buffer)
TEST_CSUM(kernel_csum );
TEST_CSUM(kernel_csum );
TEST_CSUM(kernel_csum );
TEST_CSUM(kernelpii_csum );
TEST_CSUM(kernelpiipf_csum);
TEST_CSUM(pfm_csum );
TEST_CSUM(pfm2_csum );
#undef TEST_CSUM
}
void test_copy(char *buffer)
{
unsigned sum;
puts("copy tests:");
#define TEST_COPY(a) test_one_copy(a,#a,buffer)
sum = TEST_COPY(kernel_copy );
sum == TEST_COPY(kernel_copy ) || die("Bad sum");
sum == TEST_COPY(kernel_copy ) || die("Bad sum");
sum == TEST_COPY(kernelpii_copy ) || die("Bad sum");
sum == TEST_COPY(ntqpf_copy ) || die("Bad sum");
sum == TEST_COPY(ntqpfm_copy ) || die("Bad sum");
sum == TEST_COPY(ntq_copy ) || die("Bad sum");
sum == TEST_COPY(ntqpf2_copy ) || die("Bad sum");
#undef TEST_COPY
}
int main()
{
char *buffer_raw,*buffer;
printf("Csum benchmark program\n"
"buffer size: %i K\n"
"Each test tried %i times, max and min CPU cycles are reported.\n"
"Please disregard max values. They are due to system interference only.\n",
BUFSIZE/1024,
TRY_TIMES
);
buffer_raw = malloc(NBUFS * BUFSIZE+16);
if(!buffer_raw) die("Malloc failed");
buffer = (char*) ((((int)buffer_raw)+15) & (~0xF));
test_csum(buffer);
test_copy(buffer);
puts("Done");
free(buffer_raw);
return 0;
}
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Csum and csum copyroutines benchmark
2002-10-25 13:59 ` Denis Vlasenko
2002-10-25 9:47 ` Momchil Velikov
@ 2002-10-25 10:19 ` Alan Cox
2002-10-25 16:00 ` Denis Vlasenko
1 sibling, 1 reply; 39+ messages in thread
From: Alan Cox @ 2002-10-25 10:19 UTC (permalink / raw)
To: vda
Cc: Momchil Velikov, Russell King, Roy Sigurd Karlsbakk, netdev,
Linux Kernel Mailing List
On Fri, 2002-10-25 at 14:59, Denis Vlasenko wrote:
> Well, that makes it run entirely in L0 cache. This is unrealistic
> for actual use. movntq is x3 faster when you hit RAM instead of L0.
>
> You need to be more clever than that - generate pseudo-random
> offsets in large buffer and run on ~1K pieces of that buffer.
In a lot of cases its extremely realistic to assume the network buffers
are in cache. The copy/csum path is often touching just generated data,
or data we just accessed via read(). The csum RX path from a card with
DMA is probably somewhat different.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Csum and csum copyroutines benchmark
2002-10-24 17:41 ` Denis Vlasenko
@ 2002-10-25 11:36 ` Denis Vlasenko
2002-10-25 7:48 ` Momchil Velikov
2002-10-25 14:26 ` Daniel Egger
0 siblings, 2 replies; 39+ messages in thread
From: Denis Vlasenko @ 2002-10-25 11:36 UTC (permalink / raw)
To: Russell King, Roy Sigurd Karlsbakk, netdev, Kernel mailing list
Cc: libc-alpha
[-- Attachment #1: Type: text/plain, Size: 5579 bytes --]
/me said:
> I'm experimenting with different csum_ routines in userspace now.
Short conclusion:
1. It is possible to speed up csum routines for AMD processors by 30%.
2. It is possible to speed up csum_copy routines for both AMD and Intel
three times or more. Roy, do you like that? ;)
Tests: they checksum 4MB block and csum_copy 2MB into second 2MB.
POISON=0/1 controls whether to perform correctness tests or not.
That slows down test very noticeably. What does glibc use for
memset/memcmp? for() loop?!!
With POISON=1 ntqpf2_copy bugs out, see its source. I left it in
to save repeating my work by others. BTW, i do NOT understand why
it does not work. ;) Anyone with cluebat?
IMHO the only way to make it optimal for all CPUs is to make these
functions race at kernel init and pick the best one.
tests on Celeron 1200 (100 MHz, x12 core)
=========================================
Csum benchmark program
buffer size: 4 Mb
Each test tried 16 times, max and min CPU cycles are reported.
Please disregard max values. They are due to system interference only.
csum tests:
kernel_csum - took 717 max, 704 min cycles per kb. sum=0x44000077
kernel_csum - took 4760 max, 704 min cycles per kb. sum=0x44000077
kernel_csum - took 722 max, 704 min cycles per kb. sum=0x44000077
kernelpii_csum - took 539 max, 528 min cycles per kb. sum=0x44000077
kernelpiipf_csum - took 573 max, 529 min cycles per kb. sum=0x44000077
pfm_csum - took 1411 max, 1306 min cycles per kb. sum=0x44000077
pfm2_csum - took 875 max, 762 min cycles per kb. sum=0x44000077
copy tests:
kernel_copy - took 5738 max, 3423 min cycles per kb. sum=0x99aaaacc
kernel_copy - took 3517 max, 3431 min cycles per kb. sum=0x99aaaacc
kernel_copy - took 4385 max, 3432 min cycles per kb. sum=0x99aaaacc
kernelpii_copy - took 2912 max, 2752 min cycles per kb. sum=0x99aaaacc
ntqpf_copy - took 2010 max, 1700 min cycles per kb. sum=0x99aaaacc
ntqpfm_copy - took 1749 max, 1701 min cycles per kb. sum=0x99aaaacc
ntq_copy - took 2218 max, 2141 min cycles per kb. sum=0x99aaaacc
BAD copy! <-- ntqpf2_copy is buggy :) see its source
'copy tests' above are with POISON=1
These are with POISON=0:
kernel_copy - took 2009 max, 1935 min cycles per kb. sum=0x44000077
kernel_copy - took 2240 max, 1959 min cycles per kb. sum=0x44000077
kernel_copy - took 2197 max, 1936 min cycles per kb. sum=0x44000077
kernelpii_copy - took 2121 max, 1939 min cycles per kb. sum=0x44000077
ntqpf_copy - took 667 max, 548 min cycles per kb. sum=0x44000077
ntqpfm_copy - took 651 max, 546 min cycles per kb. sum=0x44000077
ntq_copy - took 660 max, 545 min cycles per kb. sum=0x44000077
ntqpf2_copy - took 644 max, 548 min cycles per kb. sum=0x44000077
Done
Tests on Duron 650 (100 MHz, x6,5 core)
=======================================
Csum benchmark program
buffer size: 4 Mb
Each test tried 16 times, max and min CPU cycles are reported.
Please disregard max values. They are due to system interference only.
csum tests:
kernel_csum - took 1090 max, 1051 min cycles per kb. sum=0x44000077
kernel_csum - took 1080 max, 1052 min cycles per kb. sum=0x44000077
kernel_csum - took 1178 max, 1058 min cycles per kb. sum=0x44000077
kernelpii_csum - took 1614 max, 1052 min cycles per kb. sum=0x44000077
kernelpiipf_csum - took 976 max, 962 min cycles per kb. sum=0x44000077
pfm_csum - took 755 max, 746 min cycles per kb. sum=0x44000077
pfm2_csum - took 749 max, 745 min cycles per kb. sum=0x44000077
copy tests:
kernel_copy - took 1251 max, 1072 min cycles per kb. sum=0x99aaaacc
kernel_copy - took 1363 max, 1072 min cycles per kb. sum=0x99aaaacc
kernel_copy - took 1352 max, 1072 min cycles per kb. sum=0x99aaaacc
kernelpii_copy - took 1132 max, 1014 min cycles per kb. sum=0x99aaaacc
ntqpf_copy - took 514 max, 480 min cycles per kb. sum=0x99aaaacc
ntqpfm_copy - took 495 max, 482 min cycles per kb. sum=0x99aaaacc
ntq_copy - took 1153 max, 948 min cycles per kb. sum=0x99aaaacc
BAD copy! <-- ntqpf2_copy is buggy :) see its source
'copy tests' above are with POISON=1
These are with POISON=0:
kernel_copy - took 1145 max, 871 min cycles per kb. sum=0x44000077
kernel_copy - took 879 max, 871 min cycles per kb. sum=0x44000077
kernel_copy - took 876 max, 871 min cycles per kb. sum=0x44000077
kernelpii_copy - took 1019 max, 845 min cycles per kb. sum=0x44000077
ntqpf_copy - took 2972 max, 229 min cycles per kb. sum=0x44000077
ntqpfm_copy - took 248 max, 245 min cycles per kb. sum=0x44000077
ntq_copy - took 460 max, 452 min cycles per kb. sum=0x44000077
ntqpf2_copy - took 390 max, 340 min cycles per kb. sum=0x44000077
Done
--
vda
[-- Attachment #2: timing_csum_copy.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 6589 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Csum and csum copyroutines benchmark
2002-10-25 7:48 ` Momchil Velikov
@ 2002-10-25 13:59 ` Denis Vlasenko
2002-10-25 9:47 ` Momchil Velikov
2002-10-25 10:19 ` Alan Cox
0 siblings, 2 replies; 39+ messages in thread
From: Denis Vlasenko @ 2002-10-25 13:59 UTC (permalink / raw)
To: Momchil Velikov
Cc: Russell King, Roy Sigurd Karlsbakk, netdev, Kernel mailing list
[please drop libc from CC:]
On 25 October 2002 05:48, Momchil Velikov wrote:
>> Short conclusion:
>> 1. It is possible to speed up csum routines for AMD processors
>> by 30%.
>> 2. It is possible to speed up csum_copy routines for both AMD
>> andd Intel three times or more.
> Additional data point:
>
> Short summary:
> 1. Checksum - kernelpii_csum is ~19% faster
> 2. Copy - lernelpii_csum is ~6% faster
>
> Dual Pentium III, 1266Mhz, 512K cache, 2G SDRAM (133Mhz, ECC)
>
> The only changes I made were to decrease the buffer size to 1K (as I
> think this is more representative to a network packet size, correct
> me if I'm wrong) and increase the runs to 1024. Max values are
> worthless indeed.
Well, that makes it run entirely in L0 cache. This is unrealistic
for actual use. movntq is x3 faster when you hit RAM instead of L0.
You need to be more clever than that - generate pseudo-random
offsets in large buffer and run on ~1K pieces of that buffer.
> HOWEVER ...
>
> sometimes (say 1/30) I get the following output:
Csum benchmark program
buffer size: 1 K
Each test tried 1024 times, max and min CPU cycles are reported.
Please disregard max values. They are due to system interference only.
csum tests:
kernel_csum - took 958 max, 740 min cycles per kb. sum=0x44000077
kernel_csum - took 748 max, 740 min cycles per kb. sum=0x44000077
kernel_csum - took 752 max, 740 min cycles per kb. sum=0x44000077
kernelpii_csum - took 624 max, 600 min cycles per kb. sum=0x44000077
kernelpiipf_csum - took 877211 max, 601 min cycles per kb. sum=0x44000077
Bad sum
Aborted
> which is to say that pfm_csum and pfm2_csum results are not to be
> trusted (at least on PIII (or my kernel CONFIG_MPENTIUMIII=y
> config?)).
No, it's my fault. Those routines are fast-hacked together, they
are actually can csym too little. I didn't get to handle arbitrary
buffer length, assuming it it a large power of two. See the source.
--
vda
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Csum and csum copyroutines benchmark
2002-10-25 11:36 ` Csum and csum copyroutines benchmark Denis Vlasenko
2002-10-25 7:48 ` Momchil Velikov
@ 2002-10-25 14:26 ` Daniel Egger
1 sibling, 0 replies; 39+ messages in thread
From: Daniel Egger @ 2002-10-25 14:26 UTC (permalink / raw)
To: vda; +Cc: Kernel mailing list
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
Am Fre, 2002-10-25 um 13.36 schrieb Denis Vlasenko:
On Via Ezra 667 I get this:
Csum benchmark program
buffer size: 4 Mb
Each test tried 16 times, max and min CPU cycles are reported.
Please disregard max values. They are due to system interference only.
csum tests:
kernel_csum - took 2739 max, 2727 min cycles per kb. sum=0x44000077
kernel_csum - took 2733 max, 2727 min cycles per kb. sum=0x44000077
kernel_csum - took 2733 max, 2727 min cycles per kb. sum=0x44000077
kernelpii_csum - took 2691 max, 2686 min cycles per kb. sum=0x44000077
copy tests:
kernel_copy - took 2044 max, 2014 min cycles per kb. sum=0x44000077
kernel_copy - took 2026 max, 2016 min cycles per kb. sum=0x44000077
kernel_copy - took 2061 max, 2016 min cycles per kb. sum=0x44000077
kernelpii_copy - took 1526 max, 1523 min cycles per kb. sum=0x44000077
Done
The nt* functions do not work on this CPU.
--
Servus,
Daniel
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Csum and csum copyroutines benchmark
2002-10-25 10:19 ` Alan Cox
@ 2002-10-25 16:00 ` Denis Vlasenko
0 siblings, 0 replies; 39+ messages in thread
From: Denis Vlasenko @ 2002-10-25 16:00 UTC (permalink / raw)
To: Alan Cox
Cc: Momchil Velikov, Russell King, Roy Sigurd Karlsbakk, netdev,
Linux Kernel Mailing List
On 25 October 2002 08:19, Alan Cox wrote:
> On Fri, 2002-10-25 at 14:59, Denis Vlasenko wrote:
> > Well, that makes it run entirely in L0 cache. This is unrealistic
> > for actual use. movntq is x3 faster when you hit RAM instead of L0.
> >
> > You need to be more clever than that - generate pseudo-random
> > offsets in large buffer and run on ~1K pieces of that buffer.
>
> In a lot of cases its extremely realistic to assume the network
> buffers are in cache. The copy/csum path is often touching just
> generated data, or data we just accessed via read(). The csum RX path
> from a card with DMA is probably somewhat different.
'Touching' is not interesting since it will pump data
into cache, no matter how you 'touch' it.
Running benchmarks against 1K static buffer makes cache red hot
and causes _all writes_ to hit it. It may lead to wrong conclusions.
Is _dst_ buffer of csum_copy going to be used by processor soon?
If yes, we shouldn't use movntq, we want to cache dst.
If no, we should by all means use movntq.
If sometimes, then optimal strategy does not exist. :(
--
vda
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2002-10-25 14:29 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-23 10:18 tuning linux for high network performance? Roy Sigurd Karlsbakk
2002-10-23 11:06 ` [RESEND] " Roy Sigurd Karlsbakk
2002-10-23 13:01 ` bert hubert
2002-10-23 13:21 ` David S. Miller
2002-10-23 13:42 ` Roy Sigurd Karlsbakk
2002-10-23 17:01 ` bert hubert
2002-10-23 17:10 ` Ben Greear
2002-10-23 17:11 ` Richard B. Johnson
2002-10-23 17:12 ` Nivedita Singhvi
2002-10-23 17:56 ` Richard B. Johnson
2002-10-23 18:07 ` Nivedita Singhvi
2002-10-23 18:30 ` Richard B. Johnson
2002-10-24 4:11 ` David S. Miller
2002-10-24 9:37 ` Karen Shaeffer
2002-10-24 10:30 ` sendfile64() anyone? (was [RESEND] tuning linux for high network performance?) Roy Sigurd Karlsbakk
2002-10-24 10:47 ` David S. Miller
2002-10-24 11:07 ` Roy Sigurd Karlsbakk
2002-10-23 13:41 ` [RESEND] tuning linux for high network performance? Roy Sigurd Karlsbakk
2002-10-23 14:59 ` Nivedita Singhvi
2002-10-23 15:26 ` O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?) Roy Sigurd Karlsbakk
2002-10-23 16:34 ` Nivedita Singhvi
2002-10-23 16:34 ` Nivedita Singhvi
2002-10-24 10:14 ` Roy Sigurd Karlsbakk
2002-10-24 10:46 ` David S. Miller
2002-10-24 10:46 ` David S. Miller
2002-10-23 18:01 ` [RESEND] tuning linux for high network performance? Denis Vlasenko
2002-10-23 13:36 ` Roy Sigurd Karlsbakk
2002-10-24 16:22 ` Denis Vlasenko
2002-10-24 11:50 ` Russell King
2002-10-24 12:42 ` bert hubert
2002-10-24 17:41 ` Denis Vlasenko
2002-10-25 11:36 ` Csum and csum copyroutines benchmark Denis Vlasenko
2002-10-25 7:48 ` Momchil Velikov
2002-10-25 13:59 ` Denis Vlasenko
2002-10-25 9:47 ` Momchil Velikov
2002-10-25 10:19 ` Alan Cox
2002-10-25 16:00 ` Denis Vlasenko
2002-10-25 14:26 ` Daniel Egger
2002-10-23 14:52 ` [RESEND] tuning linux for high network performance? Nivedita Singhvi
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.