From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWtqV-000535-U1 for qemu-devel@nongnu.org; Mon, 18 Jan 2010 10:48:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWtqQ-0004zi-UZ for qemu-devel@nongnu.org; Mon, 18 Jan 2010 10:48:51 -0500 Received: from [199.232.76.173] (port=53154 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWtqQ-0004zd-R4 for qemu-devel@nongnu.org; Mon, 18 Jan 2010 10:48:46 -0500 Received: from mx20.gnu.org ([199.232.41.8]:62949) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NWtqO-0006Uh-Jr for qemu-devel@nongnu.org; Mon, 18 Jan 2010 10:48:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWtq1-0007lT-Dd for qemu-devel@nongnu.org; Mon, 18 Jan 2010 10:48:21 -0500 Date: Mon, 18 Jan 2010 17:45:10 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCHv2 1/3] qemu: memory notifiers Message-ID: <20100118154510.GA14828@redhat.com> References: <20100104194904.GB21299@redhat.com> <4B545C03.40807@redhat.com> <20100118135234.GC8317@redhat.com> <4B54691B.7090601@redhat.com> <20100118144456.GD8317@redhat.com> <4B54759A.1030208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B54759A.1030208@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: gleb@redhat.com, qemu-devel@nongnu.org On Mon, Jan 18, 2010 at 04:52:10PM +0200, Avi Kivity wrote: > On 01/18/2010 04:44 PM, Michael S. Tsirkin wrote: >> >> >>>> The point is that clients can be registered at any point. >>>> >>>> A client that registered when memory is present needs to >>>> be notified about it. >>>> >>>> >>> It looks very expensive. >>> >> Shouldn't be hard to optimize ... >> > > It's O(memory size), which can be very big. cpu_register_physical_memory_offset already is O(memory size) btw. >>> Maybe we mandate clients be registered at init-time? >>> >> >> This might be tricky - vhost currently only registers when the >> first device is hot-added. >> > > I see. > > Maybe coalesce adjacent pages and call the callback with the ranges? Hmm, it turns out to be tricky: it seems whether we can do this really depends on what get_ram_ptr returns ... Can't we just rely on callback to do the coalescing? > -- > error compiling committee.c: too many arguments to function