Date: Thu, 12 May 2011 13:52:56 -0500 From: Mark Tinguely <marktinguely@gmail.com> To: =?KOI8-R?Q?=F7=CC=C1=C4=C9=CD=C9=D2_=E6=C5=DD=C5=CE=CB=CF?= <vladimir-its@yandex.ru> Cc: freebsd-arm@freebsd.org Subject: Re: S3C2440A strange perfomance issue Message-ID: <4DCC2C88.3030809@gmail.com> In-Reply-To: <881651305221476@web156.yandex.ru> References: <578421305188959@web64.yandex.ru> <4DCBEB00.3040608@gmail.com> <881651305221476@web156.yandex.ru>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On 5/12/2011 12:31 PM, Владимир Фещенко wrote:
> 12.05.2011, 18:13, "Mark Tinguely"<marktinguely@gmail.com>:
>> On 5/12/2011 3:29 AM, Владимир Фещенко wrote:
>>
>>> %cc -O0 -o test test.c
>>>
>>> and execute it:
>>>
>>> Code:
>>>
>>> %/usr/bin/time -l ./test
>>> 120.16 real 119.44 user 0.16 sys
>>> 12177 involuntary context switches
>>>
>>> time of execution is over 120 sec ... but after system reboot:
>>>
>>> Code:
>>>
>>> %/usr/bin/time -l ./test
>>> 2.85 real 2.55 user 0.25 sys
>>> 292 involuntary context switches
>>>
>>> execution time is 2.85(!) sec, but it's not all!
>>>
>>> Code:
>>>
>>> %cat test> /dev/null
>>>
>>> %/usr/bin/time -l ./test
>>> 120.40 real 119.51 user 0.23 sys
>>> 12201 involuntary context switches
>>>
>>> Once the file has been opened for reading (cat test> /dev/null), execution time again increased to 120 sec (until the next reboot).
>>>
>>> What is it?!
>> Sounds like the executable cache gets disabled on the executable page
>> that is also writable issue that we talked about year or so ago. If you
>> want a quick test, in pmap_fix_cache(), and exit the routine immediately
>> if the mapping is executable. I did some tracing, and there are cases
>> where this is not the correct solution - executable mappings that are
>> really shared and cache should be disabled. I have a idea level patch
>> for this but never tested it well enough.
>>
>> I also notice a huge jump in "involuntary context switch" counts in your
>> runs.
>>
>> --Mark Tinguely
> please, i want code sample for use pmap_fix_cache() :)
> may be this issue is caching problem ... but why 'open for read' make this effect?
If the page is still in a kernel mapping (mapped to do I/O) then the
cache sharing rules are applied to turn off caching.
Below should bypass cache disabling if the page is executable. Quick
test only:
*** arm/arm/pmap.c.orig Thu May 12 13:31:35 2011
--- arm/arm/pmap.c Thu May 12 13:37:00 2011
*************** pmap_fix_cache(struct vm_page *pg, pmap_
*** 1313,1318 ****
--- 1313,1321 ----
mtx_assert(&vm_page_queue_mtx, MA_OWNED);
+ if (pv->pv_flags & PVF_EXEC)
+ return();
+
/* the cache gets written back/invalidated on context switch.
* therefore, if a user page shares an entry in the same page or
* with the kernel map and at least one is writable, then the
--Mark
[-- Attachment #2 --]
*** arm/arm/pmap.c.orig Thu May 12 13:31:35 2011
--- arm/arm/pmap.c Thu May 12 13:37:00 2011
*************** pmap_fix_cache(struct vm_page *pg, pmap_
*** 1313,1318 ****
--- 1313,1321 ----
mtx_assert(&vm_page_queue_mtx, MA_OWNED);
+ if (pv->pv_flags & PVF_EXEC)
+ return();
+
/* the cache gets written back/invalidated on context switch.
* therefore, if a user page shares an entry in the same page or
* with the kernel map and at least one is writable, then the
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DCC2C88.3030809>