Performance of SheevaPlug on 8-stable
Mark Tinguely
tinguely at casselton.net
Wed Mar 10 18:07:16 UTC 2010
On Wed, 10 Mar 2010 16:53pm, Rafal Jaworowski asks:
>
> On 2010-03-08, at 15:29, Maks Verver wrote:
>
> > Next up, this patch:
> >=20
> >> http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff
> >=20
> > No idea what this does, but it helps a lot:
> >=20
> > %time ./test
> > 9.000u 0.000s 0:09.11 99.2% 40+1324k 0+0io 0pf+0w
> >=20
> > That's much better than the 280+ seconds from before. But it's still
> > nearly twice as long as Linux takes.
> >=20
> > 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.
>
> Mark,
> Can you confirm this worsening over time happens with a fresh (from =
> scratch) kernel build (with Mark T. patch applied)? Please provide the =
> scenario / steps which lead to this behaviour.
>
> Rafal
I believe there is still a path that md.pv_kva is not being zeroed before
the page is freed. Later, when the page is re-mapped either for data or
executable, we think (because md.pv_kva is non-zero), that this page is still
mapped into the KVA stored at md.pv_kva.
My patch was for two places in the the machine dependant code that
we were not freeing the md.pv_kva.
We can prove this theory by placing a temporary printf statement or
even better a panic in vm_page_free_toq(). Something like:
if (m->hold_count != 0) {
m->flags &= ~PG_ZERO;
vm_page_enqueue(PQ_HOLD, m);
} else {
+ KASSERT(!m->md.pv_kva,
+ ("vm_page_free_toq: pva nonzero %p", m->md.pv_kva));
/*
* Restore the default memory attribute to the page.
*/
if (pmap_page_get_memattr(m) != VM_MEMATTR_DEFAULT)
pmap_page_set_memattr(m, VM_MEMATTR_DEFAULT);
Since the machine indepentant sources look pretty consistent on
pmap_qenter/pmap_qremove calls, I bet one of the pmap_remove* routines
will be freeing the page and in the panic traceback. pmap_remove*
was not the path I was expecting the kernel mapped page to be removed.
--Mark Tinguely
More information about the freebsd-arm
mailing list