On Sat, Dec 03, 2005 at 02:37:59PM -0500, jamal wrote: > 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 ..
TBH, I'm not interested in a fishing expedition right now. When someone presents a particular prefetch which is measurably hurting performance, then we can look at that implementation to see if the cache controller is issuing multiple requests for the same cacheline (or not). > 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. sure - false positives are one of the details of the "cost of prefetch". > > 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 ;-> Sorry - you are right. He wanted to defer the discussion until we had a real example(s) where the prefetching hurts performance. I'll leave it at that too. thanks, grant - 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
