From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH v2 6/8] kvm tools: Add rwlock wrapper
Date: Mon, 30 May 2011 16:43:03 +0200
Message-ID: <20110530144303.GA13966@elte.hu>
References: <1306753954.14564.92.camel@lappy>
 <20110530202646.eff0ea28.yoshikawa.takuya@oss.ntt.co.jp>
 <4DE381DB.8040804@redhat.com>
 <20110530114949.GD22324@elte.hu>
 <BANLkTi=m-mqYJetF6mszkbXX71dQ3G3cEA@mail.gmail.com>
 <1306756681.14564.95.camel@lappy>
 <20110530122027.GJ22324@elte.hu>
 <4DE38C50.404@redhat.com>
 <20110530141058.GA12360@elte.hu>
 <4DE3A9E8.4010307@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Sasha Levin <levinsasha928@gmail.com>,
	Pekka Enberg <penberg@kernel.org>,
	Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>,
	kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com,
	prasadjoshi124@gmail.com,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	takuya.yoshikawa@gmail.com
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx3.mail.elte.hu ([157.181.1.138]:57523 "EHLO mx3.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756720Ab1E3OnN (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 30 May 2011 10:43:13 -0400
Content-Disposition: inline
In-Reply-To: <4DE3A9E8.4010307@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


* Avi Kivity <avi@redhat.com> wrote:

> On 05/30/2011 05:10 PM, Ingo Molnar wrote:
> >>  [...]  Windows has a zeroing thread which causes all of RAM to be
> >>  committed shortly after boot, though.
> >
> > heh, maybe they read lkml and copied my ancient idea:
> >
> >   http://people.redhat.com/mingo/clearpage-patches/clearpage-2.3.18-J1
> >
> > An earlier version had a 'zerod' (page zeroing kernel thread).
> >
> > This was one of my more stupid ideas btw.
> >
> 
> I think that with a dma engine it makes sense.  We've got an extra 
> resource, why not utilize it in the background?  Some workloads 
> generate a lot of demand for zero pages.

It was one of the early ideas to use DMA engines to clear memory 
slowly in the background.

> I agree that using the cpu to clear memory is not a good idea, it 
> just causes cache pollution.

Yeah, but even cache-neutral clearing (either driven from the CPU 
from the idle thread or by a DMA engine) is not a particularly good 
idea: because it uses up a finite resource: memory bandwidth. Can we 
create 'idle' DMA transactions - once that never get in the way of 
real DMA transactions?

Also, a profile of a typical kernel build shows:

     0.69% cc1 [kernel.kallsyms] [k] clear_page_c
     0.49% cc1 [kernel.kallsyms] [k] page_fault

So while we could improve it, the question is, can we do this without 
accidentally slowing things down by more than 0.69%? And kernel 
builds are a pretty clear_page_c() intense workload.

Thanks,

	Ingo