From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTP id A828B67BB8 for ; Thu, 8 Jun 2006 08:55:53 +1000 (EST) In-Reply-To: <20060606164646.GA3161@w-mikek2.ibm.com> References: <20060531204144.GA7909@w-mikek2.ibm.com> <17534.30511.192632.558778@localhost.localdomain> <20060606164646.GA3161@w-mikek2.ibm.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: From: Segher Boessenkool Subject: Re: Collecting hypervisor call stats Date: Thu, 8 Jun 2006 00:57:09 +0200 To: Mike Kravetz Cc: Bryan Rosenburg , Christopher Yeoh , linuxppc-dev@ozlabs.org, Chris Yeoh List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > Can you explain the need for barrier(s) before and after the call > to the > real routine? It usually takes me a couple days of thought to > figure out > exactly where these are needed. :) The barriers make the timing ever so slightly more deterministic (not more "accurate" though), because it has a "sync" insn in it. The sc insn to do the actual hypervisor call is a synchronisation point itself of course, as probably some things around it are as well. So just blast-em away, they do slow down things, and you don't really care about a few cycles more or less reported, hypervisor calls are not that fast. Segher