Alexander Logvinov <avl_at_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.Received on Sun Jan 24 2010 - 04:45:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:00 UTC