On 2012-10-19 12:18 AM, Tim Harvey wrote:
> On Thu, Oct 18, 2012 at 1:48 PM, Felix Fietkau <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     On 2012-10-18 10:44 PM, Tim Harvey wrote:
>     > There are 2 target's affected - I figured it belonged in a global
>     area.
>     >  I only have the cns3xxx target. If you feel this should be
>     changed I'll
>     > re-submit it for just that target.
>     That doesn't explain why you want to add a configuration option for it.
>     Who would want to configure this instead of only having a sane default.
> 
>     - Felix
> 
> 
> I'm not saying enabling L2X0 is not 'sane', I just want to provide the
> user a way to optionally disable it.  If your asking why, I thought I
> explained it well enough in the description of the option in Config.in.
> 
> If you want some performance numbers to back it up I took at GW2388
> (600MHz dual-core ARM11 cns3xxx) with OpenWrt trunk on it and configured
> it for 'bridging' (low CPU overhead, high I/O overhead).  Using iperf I
> tested TCP performance and found a 63% improvement in performance with
> L2X0 disabled.  Testing gzip showed a 58% decrease in performance with
> L2X0 disabled.
> 
> With I/O bound operations the benefit of L2X0 does not outweigh the cost
> (setting up DMA etc) as there is little cache thrashing.   With
> CPU/memory bound operations the benefit of L2X0 is worth the cost.
> 
> Many of our customers use our boards in scenarios where L2X0 disabled
> provides the best performance.  I would rather have a nice clean openwrt
> .config for this rather than have them hack at
> target/linux/cns3xxx/config-3.3.
> 
> Please explain if you think I'm going about this completely wrong.
OK, these differences are much bigger than I expected. However, from the
looks of how the code works, it should be easy to add a kernel command
line option for either enabling or disabling the l2x0 cache controller.
I think this is a lot more useful than choosing l2x0 support at
compile-time. It would allow the default builds to properly cover more
usage scenarios.

- Felix
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to