From owner-freebsd-hackers@freebsd.org Fri Mar 18 20:11:16 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D248AD5D7F for ; Fri, 18 Mar 2016 20:11:16 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 47E771948; Fri, 18 Mar 2016 20:11:16 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id g184so93019543ioa.3; Fri, 18 Mar 2016 13:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=J0YlUPekAhiRacOUrIaBuw1Vi+1XUEMTjfflni3hPuI=; b=p9Zr2MlE8p5A6a4mN0cTwsn9FwXu6hrzNH/5BPsf7KR2iBWbgxn/78LvaVLDiQ6J4H WaD8F19w9WV/ZNh90Ufcot7bHj3+S+iUFczucEpdlRX9mwc9je1vtbMMlwuSivdo9FF8 TI2BgrZaX7qdEIrIeSFIhphOCbz4+NLsA7h60/39IYg4JP6URCXrm6flBECPcAKgrqgd 04xakIKZDSX+5vHx3j6JhTwi0mxEf/fSeed6YI8n09tnUMrIyooeLPWeNuzrQCMhN8lX ecEYb/jTN5g3+mfR6j6xPZ1R6StkYyjQvI6Yt4Cse4bmBApDa6lyQrNsNlyJdBin+8iN u6lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=J0YlUPekAhiRacOUrIaBuw1Vi+1XUEMTjfflni3hPuI=; b=R0/d2PS1v5J7FaymUZIVfLJcsZcCRmQKmnUiuT7mb9I2XIHfUrXQ+PvR6YCab9+nFD +UU/YbqyW8zMkz9SUKJdjKECK/Hc5belDTuc3ab/bdxqYc37D62Ol3FwBTV6FZMcljh+ tZaUYF8fFruE2l/y/n08HnKVGWMXTsOE46eS2oDp3k/WnA5z1fEkFAgndmf5RLyhoSWb nVWavYO2wr7NwiqzfPWFd897+smQzO+HM0svG9k8qddVWl7AxFR5N0+TAvy8RJHjjrtn gRcPky9yl3HzgSsNOIy+Vumg1zn6boRqtIbFASuK9/tbvij9kMYAbo+vIIDiqq7ncSRI YnyA== X-Gm-Message-State: AD7BkJIoWdGNpz64jLWCnCXEyJfMrC5wYdxtK8a0rtpcfIC8QsaJ6idZzHiyJzI5ghyw/Y1BeCeRxf3mZbKE+g== MIME-Version: 1.0 X-Received: by 10.107.7.194 with SMTP id g63mr17410721ioi.81.1458331875596; Fri, 18 Mar 2016 13:11:15 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.132.81 with HTTP; Fri, 18 Mar 2016 13:11:15 -0700 (PDT) In-Reply-To: <3213721.SRyKE0LtiG@ralph.baldwin.cx> References: <59BA610B-3754-43D6-839D-84FEE8F13CF7@FreeBSD.org> <3213721.SRyKE0LtiG@ralph.baldwin.cx> Date: Fri, 18 Mar 2016 13:11:15 -0700 X-Google-Sender-Auth: Dm1yPy5d7ObJnEKUspPAfn-zjzk Message-ID: Subject: Re: Peformance issues with r278325 From: "K. Macy" To: John Baldwin Cc: Stanislav Sedov , Adrian Chadd , Konstantin Belousov , Ryan Stone , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 20:11:16 -0000 On Friday, March 18, 2016, John Baldwin wrote: > On Friday, March 18, 2016 11:58:19 AM Stanislav Sedov wrote: > > > > > On Mar 18, 2016, at 11:49 AM, Ryan Stone > wrote: > > > > > > On Fri, Mar 18, 2016 at 1:37 PM, John Baldwin > 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 mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " >