Robert,

Very interesting results - i would like to comment; but let me post my
results first.

I recompiled all kernels from scratch and made sure that flow control
was off in all cases.

I still test with two flows .. will get to something like 32K flows
perhaps tommorow (keeping my fingers crossed that i will have the
hardware and time):

kernel 2.6.11.7 (native e1000): 446Kpps
kernel 2.6.14 (native e1000): 452kpps

Kernel 2.6.14 + e1000-6.2.15 prefetch off copybreak off: 451Kpps
kernel 2.6.14 + e1000-6.2.15 prefetch off copybreak on: 450Kpps
Kernel 2.6.14 + e1000-6.2.15 prefetch on copybreak off: 460Kpps
kernel 2.6.14 + e1000-6.2.15 as is (prefetch on copybreak on): 485Kpps

Conclusion:
-----------

1) Let me say that there is performance improvement and it has to do
with prefetching. I agree with Roberts analysis that only _some_
prefetches are valuable. Robert has narrowed them down, I will try to
validate further.
*** Note, this was my contention as well all along against this patch
based on experiences from D Mosbergers changes.

2) copybreak _does not_ add any value. In my case it doesnt seem to harm
but i dont see why i should turn it on at all.
Note, however that as soon as i turn copybreak off, the numbers go
down ;->

Now for some obtuse theory as to why this happens:
I think the reason that prefetch + copybreak together have higher
numbers is because the copybreak code provides a cycle-mask that makes
the prefetches useful. i.e if you used X cycles more before using the
prefetched data, you will end up benefiting from the prefetch. It doesnt
matter if the code was doing copybreak or just looped killing a few
cycles. so copybreak is just a useless cycle chewer.

And this is why ***prefetching is dangerous***.

To prove this theory i am gonna run tests that add a simple loop which
counts down from some number X to 0. I will try to increment X
algorithmically and see where it becomes useful etc.

Hopefully i can do this quickly before i get pulled
 
cheers,
jamal




-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to