Performance on PowerQuicc8280 linux based

Performance on PowerQuicc8280 linux based

[aldo lab]

I've a system Linux based on ppc8280 platform with unstable
performance from a compiling to another.
I've a board with 2 Ethernet interfaces and I inject traffic in one of
this and analyze the number of packets that I receive in the other
one.
I obtained 60000 pkt/s the first time, the second time i recompiling
the kernel just changing some died function that is not involved in
the flow of the packet.In that case I obtained 47000 pkt/s and it
seems that moving code position change the behaviour in term of cache
functionality.
Could someone help me to understand this strange situation

Regards
Aldo

Re: Performance on PowerQuicc8280 linux based

[Jeff Mock]

I'm no big help, but the problem might be TLB related instead of cache
related.  The performance of embedded PPCs with small TLBs requiring
software assist for TLB misses can be performance sensitive to TLB misses.

jeff


aldo lab wrote:
> I've a system Linux based on ppc8280 platform with unstable
> performance from a compiling to another.
> I've a board with 2 Ethernet interfaces and I inject traffic in one of
> this and analyze the number of packets that I receive in the other
> one.
> I obtained 60000 pkt/s the first time, the second time i recompiling
> the kernel just changing some died function that is not involved in
> the flow of the packet.In that case I obtained 47000 pkt/s and it
> seems that moving code position change the behaviour in term of cache
> functionality.
> Could someone help me to understand this strange situation
> 
> Regards
> Aldo
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

Re: Performance on PowerQuicc8280 linux based

[Dan Malek]

On Nov 15, 2006, at 11:21 AM, Jeff Mock wrote:

> I'm no big help, but the problem might be TLB related instead of cache
> related.  The performance of embedded PPCs with small TLBs requiring
> software assist for TLB misses can be performance sensitive to TLB  
> misses.

The 82xx is fully cache coherent and has BATs for
mapping the kernel space.  This is not a PPC with
a small TLB, but rather one of the most efficient.
The TLBs are not an issue,  and I doubt the caches
are as well.

I don't know what kind of test is used to measure this
performance, but the first thing you must always scrutinize
are your testing methods and procedures.  Just using
a user application to measure network performance
enables a large number of variables that must be
properly understood and controlled.  Some other
thread could have switched in and stolen CPU cycles,
you could have some sampling rate and time
measurement hysteresis due to buffering,
you need to find and control such things.

Can you "undo" the changes and get the old
results?  That's the first thing I would verify,
and then verify the results are repeatable.
If that's the case, I'd carefully try to understand
what this "unrelated" change really affects
in terms of using CPU cycles.

Thanks.

	-- Dan

Re: Performance on PowerQuicc8280 linux based

[aldo lab]

If I remove the changes I'm not available to reach the previous
result, and to perform the test I use an external traffic generator (
Smartbit) and this has an hight precision.
So the problem in some way should be tied to cache but I don't know
what I can try.I blocked some critical function (in term of cpu
cycles)  in istruction cache but I didn't obtained a good result
Let me know if you have some idea

Thanks
Aldo


On 11/15/06, Dan Malek <dan@embeddedalley.com> wrote:
>
> On Nov 15, 2006, at 11:21 AM, Jeff Mock wrote:
>
> > I'm no big help, but the problem might be TLB related instead of cache
> > related.  The performance of embedded PPCs with small TLBs requiring
> > software assist for TLB misses can be performance sensitive to TLB
> > misses.
>
> The 82xx is fully cache coherent and has BATs for
> mapping the kernel space.  This is not a PPC with
> a small TLB, but rather one of the most efficient.
> The TLBs are not an issue,  and I doubt the caches
> are as well.
>
> I don't know what kind of test is used to measure this
> performance, but the first thing you must always scrutinize
> are your testing methods and procedures.  Just using
> a user application to measure network performance
> enables a large number of variables that must be
> properly understood and controlled.  Some other
> thread could have switched in and stolen CPU cycles,
> you could have some sampling rate and time
> measurement hysteresis due to buffering,
> you need to find and control such things.
>
> Can you "undo" the changes and get the old
> results?  That's the first thing I would verify,
> and then verify the results are repeatable.
> If that's the case, I'd carefully try to understand
> what this "unrelated" change really affects
> in terms of using CPU cycles.
>
> Thanks.
>
>        -- Dan
>
>