Date: Fri, 18 Mar 2011 17:51:27 +0200 From: Andriy Gapon <avg@freebsd.org> 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: <4D837F7F.2060403@freebsd.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 18/03/2011 15:56 Kostik Belousov said the following: > 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. Are there any fundamental reasons for us to not support that configuration in situations where hardware and BIOS (in x86 case) happen to support it? I am personally more interested in non-uniform topologies like one package having two cores and another having four. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D837F7F.2060403>