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) doe= sn't help. >>> >>> KDB and WITNESS/INVARIANTS disablen in kernel config > >> =C2=A0I have a similar problem with r202904 amd64 kernel with interestin= g CPU >> statistic: >> >> top output: >> >> last pid: =C2=A01885; =C2=A0load averages: =C2=A02.89, =C2=A01.56, =C2= =A00.66 =C2=A0 =C2=A0up 0+00:02:47 >> 09:31:44 >> 72 processes: =C2=A03 running, 69 sleeping >> _CPU: =C2=A00.0% user, =C2=A00.0% nice, =C2=A00.0% system, =C2=A00.0% in= terrupt, =C2=A00.0% idle_ >> Mem: 120M Active, 39M Inact, 153M Wired, 6968K Cache, 65M Buf, 3565M Fre= e >> 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.) =C2=A0Caused 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): > > =C2=A0SVN rev 202387 on 2010-01-15 16:04:30Z by attilio > > =C2=A0Handling all the three clocks (hardclock, softclock, profclock) wit= h the > =C2=A0LAPIC may lead to aliasing for softclock and profclock because freq= uencies > =C2=A0are sized in order to fit mainly hardclock. > =C2=A0atrtc used to take care of the softclock and profclock and it does = still > =C2=A0do, if the LAPIC can't handle the clocks properly. > > =C2=A0Revert the change when the LAPIC started taking charge of all three= of > =C2=A0them and let atrtc handle softclock and profclock if not explicitly > =C2=A0requested. Such request can be made setting !=3D 0 the new tunable > =C2=A0machdep.lapic_allclocks or if the new device ATPIC is not present > =C2=A0within 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 > > =C2=A0machdep.lapic_allclocks=3D1 Can you all please do: % sysctl kern.timecounter Thanks, Attilio --=20 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>