Date: Fri, 13 May 2011 10:51:48 +0400 From: =?koi8-r?B?98zBxMnNydIg5sXdxc7Lzw==?= <vladimir-its@yandex.ru> To: Mark Tinguely <marktinguely@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: S3C2440A strange perfomance issue Message-ID: <94351305269509@web20.yandex.ru> In-Reply-To: <4DCC2C88.3030809@gmail.com> References: <578421305188959@web64.yandex.ru> <4DCBEB00.3040608@gmail.com> <881651305221476@web156.yandex.ru> <4DCC2C88.3030809@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
12.05.2011, 22:52, "Mark Tinguely" <marktinguely@gmail.com>;: > š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 -- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94351305269509>