Date: Fri, 18 Mar 2016 12:52:31 -0700 From: John Baldwin <jhb@freebsd.org> To: Ryan Stone <rysto32@gmail.com> Cc: Adrian Chadd <adrian.chadd@gmail.com>, Konstantin Belousov <kostikbel@gmail.com>, Stanislav Sedov <stas@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Peformance issues with r278325 Message-ID: <3596968.BYL0ZzVcSC@ralph.baldwin.cx> In-Reply-To: <CAFMmRNz1PnzHDstZ4sgMs7aTgA_c0ydkxaFCi%2B8We6k3GG8wGw@mail.gmail.com> References: <FA50A68E-7F3D-4361-8A8A-EB7F97EF3D00@FreeBSD.org> <3277812.DVsZx4uMun@ralph.baldwin.cx> <CAFMmRNz1PnzHDstZ4sgMs7aTgA_c0ydkxaFCi%2B8We6k3GG8wGw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, March 18, 2016 02:49:19 PM Ryan Stone wrote: > On Fri, Mar 18, 2016 at 1:37 PM, John Baldwin <jhb@freebsd.org> 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. DELAY() is already using TSC there (unless the guest has disabled TSC entirely which is unlikely). Using a direct TSC deadline means that we can break out of the loop as soon as the previous IPI unpends while still having a somewhat reasonable deadline timeout while checking the status of the previous IPI at a finer granularity than 1 usec. Of course, as kib@ noted, x2APIC doesn't suffer from this at all as IPI sends are "atomic" on x2APIc,s x2APIC is a better all-around solution when available. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3596968.BYL0ZzVcSC>