Re: [PATCH][CFT] dcache-ac6-D - dcache threading

From: Andi Kleen (
Date: Fri Jun 02 2000 - 05:18:51 EST 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

> 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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:14 EST