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>