Date: Fri, 18 Mar 2016 13:11:15 -0700 From: "K. Macy" <kmacy@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Stanislav Sedov <stas@freebsd.org>, Adrian Chadd <adrian.chadd@gmail.com>, Konstantin Belousov <kostikbel@gmail.com>, Ryan Stone <rysto32@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Peformance issues with r278325 Message-ID: <CAHM0Q_MaHwJhd2YWPV3V8R8KGkM=GwPh79jyEcsaro%2B_d__e9A@mail.gmail.com> In-Reply-To: <3213721.SRyKE0LtiG@ralph.baldwin.cx> References: <FA50A68E-7F3D-4361-8A8A-EB7F97EF3D00@FreeBSD.org> <CAFMmRNz1PnzHDstZ4sgMs7aTgA_c0ydkxaFCi%2B8We6k3GG8wGw@mail.gmail.com> <59BA610B-3754-43D6-839D-84FEE8F13CF7@FreeBSD.org> <3213721.SRyKE0LtiG@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, March 18, 2016, John Baldwin <jhb@freebsd.org> wrote: > On Friday, March 18, 2016 11:58:19 AM Stanislav Sedov wrote: > > > > > On Mar 18, 2016, at 11:49 AM, Ryan Stone <rysto32@gmail.com > <javascript:;>> wrote: > > > > > > On Fri, Mar 18, 2016 at 1:37 PM, John Baldwin <jhb@freebsd.org > <javascript:;>> wrote: > > > I think I'll likely just convert it to use a direct > > > TSC delay loop always in HEAD (assuming that verifies ok in testing as > well). > > > > > > Couldn't that work incorrectly on VM guests? The tsc is not > guaranteed to be monotonic in that environment. > > > > > > > Another concern is SMP systems where the clock is not synchronized. SMP > TSC requires > > a complicated setup procedure on the system boot which is not followed > properly by all > > vendors, and I have seen some recent systems with SMP TSC skew. > > > > I'm afraid that using TSC in this code will make FreeBSD unusable on > such (arguably buggy) > > systems. > > Eh, SMP does not matter here. DELAY() already uses TSC on FreeBSD. The > current thread is pinned to a single CPU in lapic_ipi_wait(). The idea > would be to do this: > > deadline = rdtsc() + freq * delay / 1000000; > > while (rdtsc() < deadline) { > if (APIC_DELSTAT_IDLE) > return (1); > ia32_pause(); > } > > > In a VM the thread is pinned to the _vcpu_. You have no control over what physical core the underlying thread is running on. If the vcpu is migrated to a different package there is a possibility of the next TSC reading be a lower value. The rdtsc instruction reads the value of the physical core. Although I doubt this is a problem in practice, it is a possibility if vcpus are not pinned for the lifetime of the VM. -M > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org <javascript:;> mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > <javascript:;>" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHM0Q_MaHwJhd2YWPV3V8R8KGkM=GwPh79jyEcsaro%2B_d__e9A>