Date: Sat, 23 Jan 2010 23:17:54 -0600 From: Richard Todd <rmtodd@ichotolot.servalan.com> To: Alexander Logvinov <avl@logvinov.com>, freebsd-current@freebsd.org Subject: Re: Regression in -current? Message-ID: <x7sk9w5bel.fsf@ichotolot.servalan.com> In-Reply-To: <servalan.mailinglist.fbsd-current/4B5BC039.5060406@logvinov.com> (Alexander Logvinov's message of "Sun, 24 Jan 2010 11:36:25 %2B0800") References: <20100124024214.GA49252@Fluffy.Khv.RU> <4B5BC039.5060406@logvinov.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Logvinov <avl@logvinov.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x7sk9w5bel.fsf>