On Sat, 2005-03-12 at 12:00 -0700, Grant Grundler wrote: > On Sat, Dec 03, 2005 at 09:20:52AM -0500, jamal wrote:
> > > > Ok, so you seem to be saying again that for case #b above, there is no > > harm in issuing the prefetch late since the CPU wont issue a second > > fetch for the address? > > Right. > > (When that's not true, add to "cost of issueing a prefetch".) > Can we verify if this is the case _always_ or it is the case of some architectures? It does seem like an obvious optimization .. There is also a third case: c) prefetch something you will never use. Example in the driver prefetching the next descriptor which might never be used because the driver exceeds its quota of packets by the time it gets to the packet. > > I was hoping to just be able to turn off the prefetch from the driver > > when i know my hardware does well using it. > > I agree with Dave Miller - we should disable the prefetch at compile time > for the CPU/platform combinations we know don't benefit from it. > It has to be on a case-by-case basis. > I dont think Dave wants to disable at compile time ;-> That would require ifdefs which from a maintainers perspective are a pain. OTOH, I was suggesting ifdefs. > > I suspect most newer hardware wont have observable issues given that > > memory latencies have improved over the last 2-3 years; but we run on a > > lot of older hardware too. > > In general, I thought the trend was that Memory latency has > *increased* when measured in clock cycles (vs wall clock time). > And given that caches are also bigger now, prefetch should benefit > in more cases than say, 5 years ago. > Good point and nod on prefetching looking good (or to be accurate non-detrimental) on a machine today than it did 3 years ago. I suspect none of the tests the intel folks did involved any H/ware that is not state of the art. It would be nice if tests could be made on such class of machines given they are still widely deployed. 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
