Date: Sat, 19 Mar 2011 03:04:53 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@FreeBSD.org, Jung-uk Kim <jkim@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au>, Maxim Dounin <mdounin@mdounin.ru> Subject: Re: get_cyclecount(9) deprecation Message-ID: <20110319024813.N2581@besplex.bde.org> In-Reply-To: <20110318135647.GY78089@deviant.kiev.zoral.com.ua> References: <201103171436.22283.jkim@FreeBSD.org> <20110318162252.S984@besplex.bde.org> <20110318135647.GY78089@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 18 Mar 2011, Kostik Belousov wrote: > On Fri, Mar 18, 2011 at 05:26:53PM +1100, Bruce Evans wrote: > ... >> - set cputicker() has some design bugs. It assumes that the tick frequency >> is the same across all CPUs, but the TSC is per-CPU. I have an old SMP >> system with CPUs of different frequency that can demonstrate bugs from >> this. > We definitely do not support configurations with different models of > CPUs in SMP, this is what Simmetric is about. Different as in frequency > or stepping. It worked before this bug was implemented. The TSC wasn't used so the O/S didn't notice the asymmetric frequencies directly, and the O/S also didn't care about this indirectly. Now there is even more asymmetry in core frequencies, with the hardware transiently slowing down or stopping cores independently, at least for cores in different packages. Ths O/S probably can't see this directly using TSCs since the technology that changes the core's frequencies probably comes with invariant TSCs, and the O/S shouldn't care about this indirectly just like before. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110319024813.N2581>