From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 05:45:53 2010 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 B43AA106566B for ; Sun, 24 Jan 2010 05:45:53 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2718FC17 for ; Sun, 24 Jan 2010 05:45:53 +0000 (UTC) Received: by mx1.synetsystems.com (Postfix, from userid 66) id CB2D5E1A; Sun, 24 Jan 2010 00:45:52 -0500 (EST) Received: from rmtodd by servalan.servalan.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYurF-0004Cs-KN; Sat, 23 Jan 2010 23:18:11 -0600 To: Alexander Logvinov , freebsd-current@freebsd.org References: <20100124024214.GA49252@Fluffy.Khv.RU> <4B5BC039.5060406@logvinov.com> From: Richard Todd Date: Sat, 23 Jan 2010 23:17:54 -0600 In-Reply-To: (Alexander Logvinov's message of "Sun, 24 Jan 2010 11:36:25 +0800") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: Regression in -current? 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: Sun, 24 Jan 2010 05:45:53 -0000 Alexander Logvinov writes: > Hello! > > On 24.01.2010 10:43 Dima Panov wrote: >> I see a strange regression since Friday's kernel, may be it's a kqueue-related. >> While building ports, now I never see 100% load of cpu, and portupgrade -fa >> takes ~7 hours for ~40 ports. Updating to current state (~3am VLAT) doesn't help. >> >> KDB and WITNESS/INVARIANTS disablen in kernel config > I have a similar problem with r202904 amd64 kernel with interesting CPU > statistic: > > top output: > > last pid: 1885; load averages: 2.89, 1.56, 0.66 up 0+00:02:47 > 09:31:44 > 72 processes: 3 running, 69 sleeping > _CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle_ > Mem: 120M Active, 39M Inact, 153M Wired, 6968K Cache, 65M Buf, 3565M Free > Swap: 8192M Total, 8192M Free Yeah, I saw the same thing on my core2duo system (running in amd64 mode, dunno if that makes a difference.) Caused the system to go *really* slow when powerd started and decided that since CPU usage was 0.00% it could safely throttle the CPU all the way down midway thru all the rc.d/* stuff executing. :-) As near as I can tell, the culprit is this rev (and the SVN #s you quote are consistent with this being the case): SVN rev 202387 on 2010-01-15 16:04:30Z by attilio Handling all the three clocks (hardclock, softclock, profclock) with the LAPIC may lead to aliasing for softclock and profclock because frequencies are sized in order to fit mainly hardclock. atrtc used to take care of the softclock and profclock and it does still do, if the LAPIC can't handle the clocks properly. Revert the change when the LAPIC started taking charge of all three of them and let atrtc handle softclock and profclock if not explicitly requested. Such request can be made setting != 0 the new tunable machdep.lapic_allclocks or if the new device ATPIC is not present within the i386 kernel config (atrtc is linked to atpic presence). As a check, my current post-rev-202387 kernel has working clock if I boot with machdep.lapic_allclocks=1 in loader.conf, and doesn't if I leave that out, so that pretty conclusively points to those changes.