>>>>> kuznet@ms2.inr.ac.ru writes: > No matter, this ping-pong is something absolutely unavoidable anyway. > It is the thing which you have to pay for using one socket on several cpus. >> Around 650 samples are in the inline sin_zero memset, which seems odd >> since the pad size declaration works out to 0 in in.h. Is there So I missed by a line; the big thing there is the skb->foo references on the lines before where it fills in addr. Each of the four hot spots in my profile is a read reference to data in the skb. So Alexey wins the virtual beer; it's undoubtedly a cache flopping problem between the two CPUs. This seems like a moderately general problem for loopback on smp machines. I wonder if there is a structure that would let the destination process's CPU do all the skb accesses and thus avoid blowing the cache all the time. But I bet it's too dependent on scheduler, cache, and smp implementation details to be worthwhile. Anywho, this problem should not exist in the ethernet case, and indeed when I try, udp_recvmsg is not oddly high; see below. OTOH, I just can't get my thing to saturate a 100 meg ethernet. This is a smidge disappointing. Sigh. 7.66% speedo_start_xmit 7.06% speedo_interrupt 6.67% speedo_rx 3.52% ip_rcv 3.23% ip_build_xmit 2.79% __kfree_skb 2.78% ip_route_output_key 2.74% handle_IRQ_event 2.64% ip_route_input 2.62% speedo_tx_buffer_gc 2.52% udp_recvmsg 2.48% __generic_copy_to_user 2.39% udp_rcv 2.34% udp_sendmsg 2.33% ip_output 2.28% udp_queue_rcv_skb 2.07% skb_release_data 1.76% qdisc_restart 1.73% __generic_copy_from_user 1.65% dev_queue_xmit 1.48% sock_alloc_send_skb 1.45% net_rx_action 1.39% do_gettimeofday 1.38% speedo_refill_rx_buf 1.31% sock_def_write_space 1.31% sock_def_readable 1.25% kmalloc 1.20% skb_recv_datagram 1.20% alloc_skb 1.15% system_call 1.11% pfifo_fast_dequeue 1.10% pfifo_fast_enqueue 1.09% netif_rx 1.08% sock_wfree 1.03% speedo_refill_rx_buffers 1.03% kfree -- Grant Taylor - x285 - http://pasta/~gtaylor/ Starent Networks - +1.978.851.1185 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
