kumon@flab.fujitsu.co.jp writes:
Some comments from a networking perspective.
>
> (The unit is us / web-transaction)
> test1 test1-D
> 986.8 982.3 TOTAL
> 79.3 110.4 default_idle
> 30.3 42.6 cpu_idle
>
> 97.2 90.6 csum_partial_copy_generic
> 73.6 35.8 stext_lock
> 33.0 35.2 schedule
> 32.9 31.1 speedo_interrupt
> 24.4 23.6 speedo_rx
Are you using a eepro100 driver that uses mmap'ed access to the card's
registers ? Iirc mmaped access can cut a lot of the speedo_* time over
in*/out*. In the original mindcraft discussions that bit came up. I'm not
sure if the standard eepro100 driver got mmap'ed io register access yet tho
(I believe Ingo Molnar hacked his version for that and gave good results)
It may also be worth to try the e100 driver from the Intel website.
> 22.9 22.2 kmalloc
> 22.2 20.5 kfree
That requires per CPU slabs to fix. Normally the new per CPU skb cache in 2.4
should help a bit already, maybe you need to increase
/proc/sys/net/core/hot_list_len
> 20.3 18.3 speedo_start_xmit
> 19.3 18.5 tcp_v4_rcv
That is the checksum computation and hash lookup. The e100 driver would fix
a lot of that (it supports hw checksums on the later eepros)
> 9.0 8.2 ip_route_input
Interesting. Looks like the routing cache hash isn't as good as we thought.
Could you add some statistics to ipv4/route.c:ip_route_input to check
the average hash chain length or where exactly the cycles go there?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:14 EST