Date: Fri, 18 Mar 2011 22:11:55 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Jung-uk Kim <jkim@freebsd.org> Cc: freebsd-hackers@freebsd.org, Bruce Evans <brde@optusnet.com.au>, Maxim Dounin <mdounin@mdounin.ru> Subject: Re: get_cyclecount(9) deprecation Message-ID: <20110318201155.GF78089@deviant.kiev.zoral.com.ua> In-Reply-To: <201103181410.00726.jkim@FreeBSD.org> References: <201103171436.22283.jkim@FreeBSD.org> <20110319024813.N2581@besplex.bde.org> <20110319035138.H3038@besplex.bde.org> <201103181410.00726.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--dwd27Sc7ejlYAyGt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 18, 2011 at 02:09:58PM -0400, Jung-uk Kim wrote: > On Friday 18 March 2011 01:05 pm, Bruce Evans wrote: > > On Sat, 19 Mar 2011, Bruce Evans wrote: > > > On Fri, 18 Mar 2011, Kostik Belousov wrote: > > >> 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. > > > > > > ... > > > 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. > > > > Also, with virtualization, the virtualizer cannot reasonably even > > provide an invariant TSC that runs at the same rate on all cores.=20 > > It should provide an invariant TSC that claims to run at the same > > rate on all cores, but then the cores cannot run at the same rate > > except on average, since some of the cores will have to run the > > virtualizer some of the time, and it is unreasonable to distribute > > the overhead for this evenly except on average. >=20 > Ah, virtualization... It is really painful to make it reasonably=20 > correct. For example, VMware claims that all timers (including TSC=20 > and excluding RTC) runs at "apparent time", which is concept of=20 > constant ticks in virtualized guest. It also means TSCs are always=20 > "virtually" constant and synchronized across all virtual cores in=20 > guest environment. If it loses periodic timer ticks, lost ticks are=20 > "compensated" later. This also means timecounter does not exactly=20 > scale well based on realtime and its frequency fluctuates so much, if=20 > my understanding is correct: >=20 > http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf >=20 > I am not sure how others handle this but VirtualBox gives me really=20 > wacky TSC frequency sometimes. When it happens, it becomes unusably=20 > slow. So, I know something is really wrong there, too. However, Xen=20 > seems to do much smarter than that because it has its own concept of=20 > virtual TSC, thanks to its para-virtualization architecture. Most likely, all 'full-hardware' hypervisors have to disable rdtsc for guests, intercepting the instruction by trap and emulating it. This means that most basic assumptions about rdtsc are not held in virtualized environment, like relative cost or accuracy. Anyway, I was unable to make any reasonable use of virtualization except kernel debugging, which is more then satisfactory performed by QEMU. Ah, QEMU is not hypervisor. --dwd27Sc7ejlYAyGt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2DvIoACgkQC3+MBN1Mb4g0eACgma0HPQYwVhTJTaPc7YFiUt7A nW8AoJU7jXAdAVad9rnfnXLI3uCwf00l =PitS -----END PGP SIGNATURE----- --dwd27Sc7ejlYAyGt--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110318201155.GF78089>