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