This is intended to be an architecture specific function so if the CPU does support HW dma to the CPU's L2 cache, the architecture specific version of memcpy_nc() would not replace the default definition which maps memcpy_nc() to memcpy().
For CPUs like the vast majority currently available, there is a performance benefit by not reading data into the cache that won't be read a second time. On Thu, 2006-06-29 at 16:46 -0700, David Miller wrote: > From: Bryan O'Sullivan <[EMAIL PROTECTED]> > Date: Thu, 29 Jun 2006 16:34:23 -0700 > > > I'm not quite following you, though I assume you're referring to Niagara > > or Rock :-) Are you saying a memcpy_nc would do worse than plain > > memcpy, or worse than some other memcpy-like routine? > > It would do worse than memcpy. > > If you bypass the L2 cache, it's pointless because the next > agent (PCI controller, CPU thread, etc.) is going to need the > data in the L2 cache. > > It's better in that kind of setup to eat the L2 cache miss overhead in > memcpy since memcpy can usually prefetch and store buffer in order to > absorb some of the L2 miss costs. > > _______________________________________________ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > - 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
