Date: Mon, 08 Mar 2010 07:07:39 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: tinguely@casselton.net Cc: freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: Performance of SheevaPlug on 8-stable Message-ID: <20100308.070739.1102829375853659343.imp@bsdimp.com> In-Reply-To: <201003081357.o28Dvs1K030992@casselton.net> References: <20100308124117.GW11192@cicely7.cicely.de> <201003081357.o28Dvs1K030992@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <201003081357.o28Dvs1K030992@casselton.net>
Mark Tinguely <tinguely@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@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100308.070739.1102829375853659343.imp>