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.
