From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: [RFC PATCH] Adding support for coverage informations
Date: Fri, 1 Feb 2013 09:46:40 -0500
Message-ID: <20130201144639.GC7461@konrad-lan.dumpdata.com>
References: <1359407799.32148.1.camel@nemesi>
	<1359457004.12252.103.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458342@LONPMAILBOX01.citrite.net>
	<20130130213418.GC1885@konrad-lan.dumpdata.com>
	<1359622305.12252.241.camel@zakaz.uk.xensource.com>
	<7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC201058D458351@LONPMAILBOX01.citrite.net>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Frediano Ziglio <frediano.ziglio@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, "Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Fri, Feb 01, 2013 at 02:29:04PM +0000, Frediano Ziglio wrote:
> On Thu, 2013-01-31 at 08:51 +0000, Ian Campbell wrote:
> > On Wed, 2013-01-30 at 21:34 +0000, Konrad Rzeszutek Wilk wrote:
> > > > The reason why adding a new hypercall instead of a new sysctl is simply
> > > > because is easier to have a zero cost if you disable coverage
> > > > informations. The best thing would be redirect do_coverage_op to
> > > > do_ni_hypercall using linker options but even two small stub would do
> > > > (these stubs will return ENOSYS instead).
> > > 
> > > I am not sure I follow. Is the sysctl hypercall code path "longer" than
> > > the hypercall path you are introducing? What is the zero cost?
> > 
> > I don't think we care a jot about the performance of this system call
> > when coverage is disabled, it's certainly not a hot path and in any case
> > if it is a NOP it doesn't really matter anyway.
> > 
> > Ian.
> > 
> 
> It's not about the speed, it's about the bytes introduced in Xen binary.

Not sure I follow. What bytes? Just that the code size is bigger b/c it
will go through the sysctl functions? How many bytes of extra code are
talking here?