From owner-freebsd-current@freebsd.org Wed Jun 27 17:21:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E1A6102E96A for ; Wed, 27 Jun 2018 17:21:36 +0000 (UTC) (envelope-from hackagadget@gmail.com) Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com [74.125.82.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1DEF89141; Wed, 27 Jun 2018 17:21:35 +0000 (UTC) (envelope-from hackagadget@gmail.com) Received: by mail-ot0-f169.google.com with SMTP id v24-v6so3026500otk.13; Wed, 27 Jun 2018 10:21:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MnNvhJI8C5LU3CeZGO0TT+aqlCA2oa+m24K6iDuvi4A=; b=gj0qa0bxMiG9kCA/HNi16cTb4aI7QOxVutqGrz6yt1UoBiWSRFs2XQ21IR37th45sT sPKGmyrB/8Ci+CKfaJUDY6/hiXJc2XttDsSlRriPZrjsPoyHWoMNik4TFUfRwle5xz0/ V8RPsKxVBufZKbla1NtJewZdLK76L7KZ0rVw5rxqIremwrqDSWr1yBDs6YCgOTjfzDUQ 6vhMyd7PX6YtW8jE+4OuWy6/nUgv0pq5mU+2mxfbEXVZyzCYmzTQFAV6nyaMhY4d4lWB ThvcxbdABPfnNwzfpViS2UubrydbrsCl+9+mCBL4Opus1TrGVU8ojzo1RbMr+wzNkBzr 0L5g== X-Gm-Message-State: APt69E1HCD+P3iCWoxECjQoyETokKT6h5UMZZ9Ev3O0r4S7AmFte/6xC 41NG/gdvX3chjz69StgZnMBfW2tlLu4= X-Google-Smtp-Source: AAOMgpegpwj8AHxKgPLOL3883bEijPzqJIK8vDoed2+IDBGp2SOY/o/SX3rmaBAU6WhUDUaJLMN1UA== X-Received: by 2002:a9d:6385:: with SMTP id w5-v6mr4167109otk.233.1530118533485; Wed, 27 Jun 2018 09:55:33 -0700 (PDT) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com. [74.125.82.176]) by smtp.gmail.com with ESMTPSA id j29-v6sm2221713oth.60.2018.06.27.09.55.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 09:55:33 -0700 (PDT) Received: by mail-ot0-f176.google.com with SMTP id w22-v6so2955587otk.5; Wed, 27 Jun 2018 09:55:33 -0700 (PDT) X-Received: by 2002:a9d:34db:: with SMTP id t27-v6mr4210302otd.316.1530118528154; Wed, 27 Jun 2018 09:55:28 -0700 (PDT) MIME-Version: 1.0 References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> In-Reply-To: From: "Stephen J. Kiernan" Date: Wed, 27 Jun 2018 12:55:16 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: TSC calibration in virtual machines To: Alan Somers Cc: Jung-uk Kim , Andriy Gapon , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 17:21:36 -0000 On Wed, Jun 27, 2018, 12:48 PM Alan Somers wrote: > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim wrote: > > > On 06/27/2018 03:14, Andriy Gapon wrote: > > > > > > It seems that TSC calibration in virtual machines sometimes can do more > > harm > > > than good. Should we default to trusting the information provided by a > > hypervisor? > > > > > > Specifically, I am observing a problem on GCE instances where > calibrated > > TSC > > > frequency is about 10% lower than advertised frequency. And apparently > > the > > > advertised frequency is the right one. > > > > > > I found this thread with similar reports and a variety of workarounds > > from > > > administratively disabling the calibration to switching to a different > > timecounter: > > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017- > > January/000080.html > > > > We already do that for VMware hosts since r221214. > > > > https://svnweb.freebsd.org/changeset/base/221214 > > > > We should do the same for each hypervisor. > > > > Jung-uk Kim > > > > > We probably should. But why does calibration fail in the first place? If > it can fail in a VM, then it can probably fail on bare metal too. It would > be worth investigating. > The main problem is you can't be assured that the DELAY call will be accurate in those cases. Also the way that some VMs implement the rdtsc insrruction may not be as accurate as we would need. In some cases it can compound the issue. -Steve