Date: Wed, 10 Mar 2010 12:07:14 -0600 (CST) From: Mark Tinguely <tinguely@casselton.net> To: maksverver@geocities.com, raj@semihalf.com Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable Message-ID: <201003101807.o2AI7ES2061783@casselton.net> In-Reply-To: <BC70E9A7-56C4-499C-AB96-CAD98D9A92BB@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003101807.o2AI7ES2061783>