From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 15:28:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6711065686; Thu, 16 Oct 2008 15:28:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 00FD18FC26; Thu, 16 Oct 2008 15:28:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m9GFRhZK013918; Thu, 16 Oct 2008 09:27:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Oct 2008 09:28:44 -0600 (MDT) Message-Id: <20081016.092844.-1548243521.imp@bsdimp.com> To: mav@freebsd.org From: "M. Warner Losh" In-Reply-To: <48F75773.7030100@FreeBSD.org> References: <48F7121A.2010307@FreeBSD.org> <20081016.081628.43009259.imp@bsdimp.com> <48F75773.7030100@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stas@freebsd.org, freebsd-arm@freebsd.org, zbeeble@gmail.com, freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 15:28:48 -0000 In message: <48F75773.7030100@FreeBSD.org> Alexander Motin writes: : M. Warner Losh wrote: : > In message: <48F7121A.2010307@FreeBSD.org> : > Alexander Motin writes: : > : Stanislav Sedov wrote: : > : > On Wed, 15 Oct 2008 23:25:11 +0300 : > : > Alexander Motin mentioned: : > : >> Completely fortunate I have noticed that number of iterations depends on : > : >> my laptop power source. After small investigation I have found that it : > : >> actually depends on dev.cpu.0.freq value. With default value 2400 I have : > : >> only several iterations. But every double frequency decrease doubles : > : >> iteration count. With minimum value 100MHz I have more then 100 : > : >> iterations. Same time it doesn't looks like this time is a real wall : > : >> time. It looks like DELAY() used in a loop has some problems with time : > : >> counting. : > : > : > : > What do you mean? DELAY(9) on your laptop doesn't correspond to the : > : > real time? : > : : > : Yes. It works fine when laptop operates at full frequency, but : > : proportionally reduces time interval when powerd drops frequency down. I : > : have also evidence about the same problem on another laptop with : > : 7.1-PRERELEASE. : > : > Is the slower clock making DELAY take less/more time? Or is the : > slower clock fed to the SDHCI part who feeds it to the SD card so less : > time accumulates on the SD card because the clock line to it is : > running slower? : > : > : > AFAIK, DELAY(9) relies on current timecounter for time : > : > accountiong, so there might be problems with it. Have you tried : > : > switching the kern.timecounter.hardware sysctl to see if it will : > : > affect results? : > : : > : It was late and I am not very aware in FreeBSD time counting, so I have : > : not tried to investigate it deeper. : > : > I would have thought that if DELAY(10) went from 10us to 100us because : > you are battery power, you'd have more cards working rather than : > fewer.. : : No, it's opposite. With lower frequency I have proportionally smaller : delays (more loop iterations). I don't remember exact numbers now, but : general tendency was like: with 2400MHz - 10 iterations, with 1200MHz - : 20 iterations and with 100MHz - 240 iterations. But neither syslog, nor : my eyes saw any visible delay there. You have more iterations. I'd have expected less. This doesn't say anything at all about DELAY, per se. If you are waiting for 1M cycles at 100MHz, it is only .01s, while at 10MHz it is .1s. Delay is implemented by reading a counter in the 8254 that's been calibrated. So unless the clock that's clocking it is running FASTER, delay won't be the source of additional iterations. Hmmm, looking at the i386 delay code, it looks like it depends on tsc_frequency being right when tsc isn't broken. If that's set bogusly, that could cause DELAY to be slower... : It looks like working on battery power DELAY() code expects timer speed : reduced, while estimating final timer value, but looks like timer itself : runs on full speed. Have you confirmed this with getting timestamps per loop? The delay code doesn't seem to adjust at all. We should likely look at i386/i386/tsc.c and instrument it to see what it is doing to tsc_freq in your case... Warner