Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Mar 2010 19:41:47 +0100
From:      Bernd Walter <ticso@cicely7.cicely.de>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        tinguely@casselton.net, freebsd-arm@freebsd.org
Subject:   Re: Performance of SheevaPlug on 8-stable
Message-ID:  <20100308184147.GB11192@cicely7.cicely.de>
In-Reply-To: <20100308.091516.295937982770284454.imp@bsdimp.com>
References:  <201003072125.o27LPfFb000968@casselton.net> <4B951CE2.6040507@semihalf.com> <20100308.091516.295937982770284454.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 08, 2010 at 09:15:16AM -0700, M. Warner Losh wrote:
> 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...

This puzzled me as well.
What is the requirement for such a handling with shared pages?
I though handing over shared data is done by cache-flush, barriers or
whatever an architectur has for this.
Most systems we talk about are single CPU, so it is just DMA and
handing over dcache writes to icache, but we don't support self
modifying code, so it is always done in a controlled way.
And even for SMP systems handing over data requires using
cache coherence mechanisms - e.g. those embedded in mutexes.
So what is wrong in my picture and requires us to do special handling
for shared pages on ARM?

> And if there's only one copy of 'test' running, why does it hit the
> 'shared' case for this code?
> 
> Warner

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100308184147.GB11192>