Date: Mon, 08 Mar 2010 15:29:25 +0100 From: Maks Verver <maksverver@geocities.com> To: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable Message-ID: <4B9509C5.7050804@geocities.com> In-Reply-To: <201003072125.o27LPfFb000968@casselton.net> References: <201003072125.o27LPfFb000968@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/07/2010 10:25 PM, Mark Tinguely wrote: > FreeBSD-current has kernel and user witness turned on. Witness is > for locks, so it should not change the performance of a tight > arithmetic loop like this. For the record, I've been using 8-stable so far. > I don't know the marvell interals, and from what I tell, their > technial docs require NDA. Yeah, that sucks. But I don't think the SheevaPlug contains a lot of novel technology; it's just a slightly different configuration. In any case, Linux seem to have more or less complete support for the SheevaPlug (including L2 cache, SDIO and NAND flash) so for details, the GPL'ed Linux source code may be helpful. > It looks like from the cpu identification that the the branch > prediction is turned on. Branch prediction compensates for the longer > pipelines. I can't see how in the tight loop how that could go > astray. Well, since the Linux version of the test program runs exactly as well as I expect (or could ever hope for) I don't have any doubts that the CPU is able to run the tight loop efficiently. The question (for me) is why it doesn't run just as well on FreeBSD. I tried a couple of the suggestions: Mark Tingely wrote: > Thinking way out of the box ... has anyone tried this in single user > mode? I did, and it still takes 287 seconds (same as before). Petter Selasky wrote: > Was the output from "vmstat -i" and "top" posted? Note yet. vmstat -i reports: interrupt total rate irq1: timer0 130981 999 irq33: uart0 477 3 irq19: ehci0 875 6 Total 132333 1010 Which looks entirely reasonable to me. Top contains the same info as the time data I posted: 99.x% of CPU time is spent in user-mode, lots of free memory. So it seems the kernel has very little do with this. Next up, this patch: > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff No idea what this does, but it helps a lot: %time ./test 9.000u 0.000s 0:09.11 99.2% 40+1324k 0+0io 0pf+0w That's much better than the 280+ seconds from before. But it's still nearly twice as long as Linux takes. There is more weirdness though. If I freshly boot the system I get timings like these, and even nbench reports decent scores. However, if I do a couple things like rerun/recompile nbench, then at some point something 'breaks' and the performance goes back down to what it used to be. So Mark's patch definitely touches on something related to the problem, but doesn't quite solve the problem completely. I still have no clue what's going on, but I'm willing to try out suggestions if anyone has them. :-) - Maks Verver.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B9509C5.7050804>