Performance of SheevaPlug on 8-stable

[Bernd Walter]

On Mon, Mar 08, 2010 at 01:27:04AM +0100, Bernd Walter wrote:
> On Sun, Mar 07, 2010 at 03:25:41PM -0600, 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.
> 
> I have no kernel debugging enabled.
> I have no malloc.conf on current, but I have on the 8.0-current system,
> so malloc debugging is enabled on one machine, but it shouldn't hurt in
> this case since it is not allocating anything.
> 
> > I don't know the marvell interals, and from what I tell, their technial
> > docs require NDA. That said, many of the ARM processors also have a
> > instruction internal cache (instruction prefetch) in addition to the
> > instruction cache. I don't think the prefetch has an enable/disable.
> > 
> > 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.
> > 
> > Thus says the ARM ARM:
> > 
> > 	ARM implementations are free to choose how far ahead of the
> > 	current point of execution they prefetch instructions; either
> > 	a fixed or a dynamically varying number of instructions. As well
> > 	as being free to choose how many instructions to prefetch, an ARM
> > 	implementation can choose which possible future execution path to
> > 	prefetch along. For example, after a branch instruction, it can
> > 	choose to prefetch either the instruction following the branch
> > 	or the instruction at the branch target. This is known as branch
> > 	prediction.
> > 
> > There are a few data dangling allocations that I would like to see
> > closed from the multiple kernel allocation fix. *IN THEORY, IF* a page
> > is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then
> > it is never marked as unallocated. *IN THEORY*, if that page is used
> > again, then we could falsely believe that page is being shared and
> > we turn off the cache, eventhough it is not shared.
> > 
> > 	http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff
> > 
> > * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in
> > the Sheeva implementation. This is a theoritical observation of a side
> > effect of the multiple kernel mapping patch that we did just before
> > FreeBSD 8-release.

This sounds possible.
My 8.0-current system should be before that change and it is much faster
than my current system.
It is still slower than the calculated ~80s and the difference looks
a bit large to just think it is a stalled pipeline because of the branch.
Has anyone access to a RM9200 system running Linux?

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.