From owner-freebsd-arm@FreeBSD.ORG Fri May 13 06:51:52 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87CF4106564A for ; Fri, 13 May 2011 06:51:52 +0000 (UTC) (envelope-from vladimir-its@yandex.ru) Received: from forward16.mail.yandex.net (forward16.mail.yandex.net [95.108.253.141]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5948FC19 for ; Fri, 13 May 2011 06:51:51 +0000 (UTC) Received: from web20.yandex.ru (web20.yandex.ru [95.108.253.229]) by forward16.mail.yandex.net (Yandex) with ESMTP id 3EB14D42380; Fri, 13 May 2011 10:51:50 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1305269510; bh=9OIBZoFSKRtMpk/uqpLA2gNmC1aobaaRIEr9IWZGwdU=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=WJHSHUuw4/MzimrL4h6XHqmY32T6FDyhrIhcXkIzlk6XohhVnyXMvMNnqTsDC3W2e KMBePgFUgICerY5beA6koxHM6yMAivC5R2BbzL4YN2ha0rwyxUeJZT1o8yC+KcFXvZ zqW3O/3FUR5Y3Gubp8GLvN0LNOPEFdwr53WW0Vcs= Received: from localhost (localhost.localdomain [127.0.0.1]) by web20.yandex.ru (Yandex) with ESMTP id 2BB17618830D; Fri, 13 May 2011 10:51:50 +0400 (MSD) X-Yandex-Spam: 1 Received: from 91.206.19.225.base-net.ru (91.206.19.225.base-net.ru [91.206.19.225]) by mail.yandex.ru with HTTP; Fri, 13 May 2011 10:51:48 +0400 From: =?koi8-r?B?98zBxMnNydIg5sXdxc7Lzw==?= To: Mark Tinguely In-Reply-To: <4DCC2C88.3030809@gmail.com> References: <578421305188959@web64.yandex.ru> <4DCBEB00.3040608@gmail.com> <881651305221476@web156.yandex.ru> <4DCC2C88.3030809@gmail.com> MIME-Version: 1.0 Message-Id: <94351305269509@web20.yandex.ru> Date: Fri, 13 May 2011 10:51:48 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-Mailman-Approved-At: Fri, 13 May 2011 11:03:59 +0000 Cc: freebsd-arm@freebsd.org Subject: Re: S3C2440A strange perfomance issue X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 06:51:52 -0000 12.05.2011, 22:52, "Mark Tinguely" ;: > šOn 5/12/2011 12:31 PM, ÷ÌÁÄÉÍÉÒ æÅÝÅÎËÏ wrote: >> šš12.05.2011, 18:13, "Mark Tinguely";;: >>> šš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.