Performance of SheevaPlug on 8-stable

[M. Warner Losh]

In message: <201003081357.o28Dvs1K030992 at casselton.net>
            Mark Tinguely <tinguely at casselton.net> writes:
: 
: >  On Mon, Mar 08, 2010 at 10:07:14AM +0100, Hans Petter Selasky wrote:
: >  > On Monday 08 March 2010 09:25:59 Jacques Fourie wrote:
: >  > > On Mon, Mar 8, 2010 at 5:00 AM, Mark Tinguely <tinguely at casselton.net> 
: >  > wrote:
: >  > > > <deletes>
: >  > > >
: >  > > >>  It is still puzzling me why it is not near 80 seconds.
: >  > > >>  This would mean it is loosing something about 5-6 cycles.
: >  > > >>  Well - Ok - the pipeline might be that long and real loops are
: >  > > >>  mostly some instructions longer.
: >  > > >>  But I would still be interested to see Linux results on RM9200.
: >  > > >>
: >  > > >>  --
: >  > > >>  B.Walter <bernd at bwct.de> http://www.bwct.de
: >  > > >>  Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
: >  > > >
: >  > > > Thinking way out of the box ... has anyone tried this in single user
: >  > > > mode?
: >  > > >
: >  > 
: >  > Was the output from "vmstat -i" and "top" posted?
: >
: >  No, but I can say that my current and 8.0-current system had almost no
: >  load.
: >  My 7.0-current system had about 60-70% load and was about 3 times slower
: >  than the 8.0 and the patched 9.0 system, so it makes sense.
: >  Do you expect anything special to see?
: >
: >  -- 
: >  B.Walter <bernd at bwct.de> http://www.bwct.de
: >  Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
: >
: 
: The process is in a tight CPU bound loop. I am thinking that there is
: still the interrupt handler (short assembly), find the next interrupt routine
: (typically a bitmap shift loop), clock interrupt handler, scheduler,
: cpu_switch() (even if it is just to the same process) that goes off every
: 1/HZ seconds. I would think that if there is an inefficiency in the above
: loop, the times should be the same magnitude in single-user as in multi-using. 
: 
: If you cannot go to single user then the 'vmstat -i' and 'top' is a good
: idea - make sure something else is not causing a context switch which would
: flush our caches.
: 
: The performance counter idea is a good one too.
: 
: Wildly grasping, here:
: I suppose you could run the program with time and use the wall clock
: or "date; a.out; date" to eliminate some problem in the "time" command.

ntpdate might help here to eliminate any local clock effects..

Warner