S3C2440A strange perfomance issue

Владимир Фещенко vladimir-its at yandex.ru
Fri May 13 06:51:52 UTC 2011


12.05.2011, 22:52, "Mark Tinguely" <marktinguely at gmail.com>;:

>  On 5/12/2011 12:31 PM, Владимир Фещенко wrote:
>>   12.05.2011, 18:13, "Mark Tinguely"<marktinguely at 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
-- 

Thank you, Mark!
After applying of patch, execution time become a stable (3 sec) :)

You wrote:
>>>   Sounds like the executable cache gets disabled on the executable page
>>>   that is also writable issue that we talked about year or so ago.

where i can see this thread?

With respect, Vladimir.


More information about the freebsd-arm mailing list