Date: Sun, 24 Jan 2010 17:29:17 +0100 From: Attilio Rao <attilio@freebsd.org> To: Richard Todd <rmtodd@ichotolot.servalan.com> Cc: fluffy@fluffy.khv.ru, freebsd-current@freebsd.org, Alexander Logvinov <avl@logvinov.com> Subject: Re: Regression in -current? Message-ID: <3bbf2fe11001240829k46d62476pda54d149c39ae7c3@mail.gmail.com> In-Reply-To: <x7sk9w5bel.fsf@ichotolot.servalan.com> References: <20100124024214.GA49252@Fluffy.Khv.RU> <4B5BC039.5060406@logvinov.com> <servalan.mailinglist.fbsd-current/4B5BC039.5060406@logvinov.com> <x7sk9w5bel.fsf@ichotolot.servalan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/1/24 Richard Todd <rmtodd@ichotolot.servalan.com>: > 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 Can you all please do: % sysctl kern.timecounter Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe11001240829k46d62476pda54d149c39ae7c3>