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
> [email protected]
> 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 linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
