Date: Tue, 7 Feb 2012 17:10:15 -0600 From: Mark Tinguely <marktinguely@gmail.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable Message-ID: <CAP%2BM-_G6g61_TR1t5C-55Y23Ok-mKkX2DA2j%2BpSWKBod=t4pAw@mail.gmail.com> In-Reply-To: <1328507292.3546.67.camel@revolution.hippie.lan> References: <1327980703.1662.240.camel@revolution.hippie.lan> <F48E21E0-129A-418A-B147-7D5FB01160A8@bsdimp.com> <1328025245.1662.289.camel@revolution.hippie.lan> <5FB4965A-66C9-4C99-8B61-5AC605F9ECC5@bsdimp.com> <1328030999.1662.324.camel@revolution.hippie.lan> <20120204234319.GR52468@funkthat.com> <1328507292.3546.67.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 5, 2012 at 11:48 PM, Ian Lepore
<deletions>
> Okay, I've just confirmed that the problem as I described it above still
> exists in 9.0 ...
>
> =A0 =A0 =A0 =A0# uname -a
> =A0 =A0 =A0 =A0FreeBSD =A09.0-RELEASE FreeBSD 9.0-RELEASE #7: Mon Feb =A0=
6 04:38:59
> =A0 =A0 =A0 =A0UTC 2012
> =A0 =A0 =A0 =A0root@revolution.hippie.lan:/usr/obj/arm.arm/usr/src/sys/TF=
LEX
> =A0 =A0 =A0 =A0arm
>
> =A0 =A0 =A0 =A0# /usr/tsc/bin/testsimple
> =A0 =A0 =A0 =A0Elapsed 0.782453
> =A0 =A0 =A0 =A0# /usr/tsc/bin/testsimple
> =A0 =A0 =A0 =A0Elapsed 0.782539
>
> =A0 =A0 =A0 =A0# cat /usr/tsc/bin/testsimple >/dev/null
>
> =A0 =A0 =A0 =A0# /usr/tsc/bin/testsimple
> =A0 =A0 =A0 =A0Elapsed 10.090336
> =A0 =A0 =A0 =A0# /usr/tsc/bin/testsimple
> =A0 =A0 =A0 =A0Elapsed 10.090611
>
> The testsimple program is just a little loop that repeatedly assigns a
> volatile variable (had to fool the optimizer into generating some code).
> I statically linked it to avoid any variability based on the race
> between paging and readahead when loading shared libs. =A0I'm just showin=
g
> here that the base problem still exists: =A0when executable pages get int=
o
> the vfs buffer cache they (semi-)permanently lose their i-cache bit.
>
> I also applied my patches from the start of this thread and re-tested
> and they appear to still be a usable workaround for the problem in 9.
> But they are just a workaround, we need to figure out a real fix for
> this. =A0(I had to enable the #if in ffs_read() as well as the one in
> ffs_write() for this test, since my quick 'cat' test is reading the file
> to get it into the cache.)
>
> -- Ian
I dug out my files from that era.
I was looking at the cases where the page is marked executable and writable=
:
1) were they shared or single mappings?
2) are all the shared mappings executable?
3) was the page mapped several time in one process?
4) was the all the writers a kernel process?
5) was there many kernel mappings
I was think something like (pardon the bad formatting)
if (exec && (exec =3D=3D entries + kentries) &&
#ifndef test1
(writable =3D=3D 0 || (writable =3D=3D kwritable)) &&
#else
(writable =3D=3D 0 || (writable =3D=3D 1 && kwritable =3D=3D 1)) &&
#endif
(ncaches =3D=3D 0)) {
return; /* bypass the cache fix routine */
}
this test is just before the comment that says
/*
* check if the user duplicate mapping has
* been removed.
*/
I never felt brave enough with this test though.
--Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAP%2BM-_G6g61_TR1t5C-55Y23Ok-mKkX2DA2j%2BpSWKBod=t4pAw>