On Wed, Dec 07, 2005 at 02:17:16PM -0500, jamal wrote: ... > 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 would argue the other way around. copybreak would stall and hurt small packet routing performance if there was no prefetching. With agressive prefetching, copybreak takes advantage of data that is already in flight or in cache. Ideally, the prefetch should be for whatever number of cachelines the copybreak is going to touch (bounded by architectural limits and other "reasonable" criteria). > 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. I think that ignores the benefits Dave Miller pointed out with the socket buffer utilization. Copybreak is "cheap" once the data is prefetched. > 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. Please try using udelay(). That will tell you exactly how much "stall" in wallclock time the CPU is experiencing anyway because the packet data isn't in cache/register yet. I totally agree there is an interaction between copybreak and prefetching. I'm thinking more prefetching means copybreak be bumped up higher too. This gets us back to the "prefetching is arch specific optimization" I raised near the beginning of this thread. thanks, grant > > 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
