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>
index | next in thread | previous in thread | raw e-mail
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 ...
>
> # uname -a
> FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #7: Mon Feb 6 04:38:59
> UTC 2012
> root@revolution.hippie.lan:/usr/obj/arm.arm/usr/src/sys/TFLEX
> arm
>
> # /usr/tsc/bin/testsimple
> Elapsed 0.782453
> # /usr/tsc/bin/testsimple
> Elapsed 0.782539
>
> # cat /usr/tsc/bin/testsimple >/dev/null
>
> # /usr/tsc/bin/testsimple
> Elapsed 10.090336
> # /usr/tsc/bin/testsimple
> Elapsed 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. I'm just showing
> here that the base problem still exists: when executable pages get into
> 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. (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 == entries + kentries) &&
#ifndef test1
(writable == 0 || (writable == kwritable)) &&
#else
(writable == 0 || (writable == 1 && kwritable == 1)) &&
#endif
(ncaches == 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.
home |
help
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>