From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60698 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OETeA-0001Tf-Jw
	for qemu-devel@nongnu.org; Tue, 18 May 2010 16:44:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <stefanha@gmail.com>) id 1OETda-00066o-Fc
	for qemu-devel@nongnu.org; Tue, 18 May 2010 16:43:44 -0400
Received: from mail-vw0-f45.google.com ([209.85.212.45]:52707)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <stefanha@gmail.com>) id 1OETda-00066g-Ci
	for qemu-devel@nongnu.org; Tue, 18 May 2010 16:43:38 -0400
Received: by vws1 with SMTP id 1so2229004vws.4
	for <qemu-devel@nongnu.org>; Tue, 18 May 2010 13:43:37 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <AANLkTilrFcs5LVraddwN23dhURfz7BZjiDQcXgUv9LDP@mail.gmail.com>
References: <1273873950-25756-1-git-send-email-stefanha@linux.vnet.ibm.com>
	<AANLkTikjZLvQZmAIxOzfAAf3aFJII0rO5Oxpqqd4t2CV@mail.gmail.com>
	<AANLkTiluK9mvS3qz2wrIjKOxf9w0jCDLWUD65JoLcVNk@mail.gmail.com>
	<AANLkTilrFcs5LVraddwN23dhURfz7BZjiDQcXgUv9LDP@mail.gmail.com>
Date: Tue, 18 May 2010 21:43:37 +0100
Message-ID: <AANLkTinE2YwJFBAPvcAZtxiWmfAeS5OlHvnJSs6O-VDo@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH] virtio-blk: Avoid zeroing every request
	structure
From: Stefan Hajnoczi <stefanha@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Corentin Chary <corentin.chary@gmail.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, qemu-devel@nongnu.org

On Tue, May 18, 2010 at 8:55 PM, Corentin Chary
<corentin.chary@gmail.com> wrote:
> I believe that if the allocation size is large enougth, getting a
> zeroed page can be almost free with clever memory management.
> Could you try to re-run your test with calloc and see what it does ?
> Speeding up all mallocz calls is probably a good idea :)

I think that scenario is libc using mmap to grab zeroed pages from the
kernel.  If the kernel manages zeroed pages so that zeroing is
performed out-of-line (e.g. there is a pool of zeroed pages waiting),
then it appears that calloc() is getting zeroed memory cheaply.

I'll rerun with profiling tomorrow to see if calloc() makes a
difference for general qemu_mallocz() usage.

In the case of virtio-blk requests, we definitely shouldn't be
clearing that memory even if calloc() were cheaper.  Much of the
request structure will not be touched in an average I/O request.
Using zeroed pages is wasteful because they aren't needed here.

Stefan