Performance of SheevaPlug on 8-stable

[Mark Tinguely]

On Wed Mar 10 at 0:38:20am, Bernd Walter wrote:
>
>  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 pa
ge
>  > > 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.

The orginial patch is needed, but the above would imply that there are more
places that we are not removing the remberence of the kernel allocation.

The assumption was the allocations are to the kernel map and are originating
rom pmap_kenter/pmap_qenter and will be removed with pmap_kremove/pmap_qremove.
I looked at the kernel sources yesterday; pmap_qenter/pmap_qremove is used
exclusively in the machine independant code.

Maybe the pmap_qremove is not used (process termination?, another allocation
with remove?) and the page is freed instead with the pmap_remove_page,
pmap_remove_all, pmap_remove routines.

A test panic in vm_page_free_toq() on non-zero md.pv_kva will tell us
which routine is releasing the page.

I will think some more about the pmap_remove_page, pmap_remove_all, pmap_remove
paths.

--Mark Tinguely.