Kernel 2.6 on MPC8xx performance trouble...

[David Jander]

On Friday 28 October 2005 22:37, Wolfgang Denk wrote:
>[...]
> > They are just integers with fixed start values. These are in the loop, so
> > it's not an empty loop and hopefully the compiler won't out-optimize it
> > so easily (that is of course without specifying any optimization flags).
> > Please don't tell me it's a lousy benchmark, because I already know that!
> > Be it as lousy as it is, I shouldn't get _those_ results IMHO.
>
> Indeed, you should not get such results.  If  you  compare  with  the
> lmbench  results  of  our 2.4/2.6 comparison, you will notice that we
> did NOT see such behaviour. There was a  perfromnce  degradation  for
> pure  integer tests, due to increased system overhead, but far from a
> factor of 2.
> See http://www.denx.de/wiki/pub/Know/Linux24vs26/lmbench_results

I have seen them, and my conclusion is: Your kernel was working ok, while 
mine, a newer one, is broken. 
As you can see in the other e-mail I just posted (replying to Marcelo), at 
least the CPU cache seems to be disabled. Might this have something to do 
with processor model (mis-) identification?
I had to apply the "ppc_sys: do not BUG if system ID is unknown" patch from 
Marcelo Tosatti a few days back in order to be able to boot in the first 
place. I had a look at ppc_sys system identification for 8xx and it looked a 
little bit nonsensical to me, since all 8xx report the same ID. Maybe the 
intention was to set the ID "by hand" in board support and setup.
Problem is: there is still no real board-support infrastructure for mpc8xx, 
like there is for mpc82xx for example. What are the plans for 8xx? Should I 
try to emulate what others have done for some PQ2 platforms, i.e. create a 
arch/ppc/platforms/myplatform.c file and implement board_init()?

Greetings,

-- 
David Jander
Protonic Holland.