Performance of SheevaPlug on 8-stable

Bernd Walter ticso at cicely7.cicely.de
Wed Mar 10 14:38:22 UTC 2010


On Wed, Mar 10, 2010 at 03:05:14PM +0100, Rafal Jaworowski wrote:
> 
> On 2010-03-10, at 14:58, Grzegorz Bernacki wrote:
> 
> >> 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.
> > 
> > I instrumented code with KTRs and your theory is correct. Kernel reuse page
> > which was previouly mapped via arm_nocache. Your patch should be applied
> > to -current.
> 
> Bernd,
> Could you confirm this also fixes the issues for you on the RM9200 machine? If so, I'll go on and commit the changes.

For me it helped to get back to the speed of my older systems.
Someone mentioned that even with this patch the speed can still drop
after some time.

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


More information about the freebsd-arm mailing list