Date: Mon, 08 Mar 2010 09:15:16 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: gjb@semihalf.com Cc: tinguely@casselton.net, freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable Message-ID: <20100308.091516.295937982770284454.imp@bsdimp.com> In-Reply-To: <4B951CE2.6040507@semihalf.com> References: <201003072125.o27LPfFb000968@casselton.net> <4B951CE2.6040507@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
cIn message: <4B951CE2.6040507@semihalf.com>
Grzegorz Bernacki <gjb@semihalf.com> writes:
: This is probably caused by mechanism which turns of cache for shared
: pages.
: When I add applied following path:
:
: diff --git a/sys/arm/arm/pmap.c b/sys/arm/arm/pmap.c
: index 390dc3c..d17c0cc 100644
: --- a/sys/arm/arm/pmap.c
: +++ b/sys/arm/arm/pmap.c
: @@ -1401,6 +1401,8 @@ pmap_fix_cache(struct vm_page *pg, pmap_t pm,
: vm_offset_t va)
: */
:
: TAILQ_FOREACH(pv, &pg->md.pv_list, pv_list) {
: + if (pv->pv_flags & PVF_EXEC)
: + return;
: /* generate a count of the pv_entry uses */
: if (pv->pv_flags & PVF_WRITE) {
: if (pv->pv_pmap == pmap_kernel())
:
: execution time of 'test' program is:
: mv78100-4# time ./test
: 5.000u 0.000s 0:05.40 99.8% 40+1324k 0+0io 0pf+0w
:
: and without this path is:
: mv78100-4# time ./test
: 295.000u 0.000s 4:56.01 99.7% 40+1322k 0+0io 0pf+0w
:
:
: I think we need to handle executable pages in different way.
Agreed. Why would we turn off caching for shared pages? I can
understand read/write pages in a system that has a virtually index
cache with the classic cache aliasing problems as a workaround for
lousy hardware, but otherwise, this one has me scratching my head...
And if there's only one copy of 'test' running, why does it hit the
'shared' case for this code?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100308.091516.295937982770284454.imp>