From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KzRjZ-0002yw-9c for qemu-devel@nongnu.org; Mon, 10 Nov 2008 03:02:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KzRjX-0002xx-Lq for qemu-devel@nongnu.org; Mon, 10 Nov 2008 03:02:52 -0500 Received: from [199.232.76.173] (port=36798 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KzRjX-0002xo-Ep for qemu-devel@nongnu.org; Mon, 10 Nov 2008 03:02:51 -0500 Received: from mx20.gnu.org ([199.232.41.8]:44657) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KzRjW-00071Q-IR for qemu-devel@nongnu.org; Mon, 10 Nov 2008 03:02:51 -0500 Received: from mail2.shareable.org ([80.68.89.115]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KzRjR-0006gx-9H for qemu-devel@nongnu.org; Mon, 10 Nov 2008 03:02:45 -0500 Date: Mon, 10 Nov 2008 08:02:34 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH, v2] Rewrite mmap_find_vma() to work fine on 64-bit hosts with 32-bit targets Message-ID: <20081110080234.GA18267@shareable.org> References: <1223892640-15545-11-git-send-email-kirill@shutemov.name> <1225129768-11603-1-git-send-email-kirill@shutemov.name> <20081101165110.GA6991@shareable.org> <20081101165543.GA5076@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: andrzej zaborowski Cc: qemu-devel@nongnu.org andrzej zaborowski wrote: > Hi, > > 2008/11/1 Kirill A. Shutemov : > > On Sat, Nov 01, 2008 at 04:51:10PM +0000, Jamie Lokier wrote: > >> Kirill A. Shutemov wrote: > >> > + /* Unmap and try again with new page */ > >> > + munmap(ptr, size); > >> > addr += qemu_host_page_size; > >> > >> Won't this be rather slow if it has to skip a large mapped area, one > >> page at a time? > > > > If we skip more than one page we increase memory fragmentation. > > This approach makes sense, however the iterating over all pages may > indeed have performance consequences, plus it would be great if people > who better know linux-user/ than me commented. I'll assume that > everyone is happy with this otherwise. Just briefly to mention that binary search using shorter probe-mappings can eliminate the page-by-page iteration in this case, but alas I don't have time in this email to explain how :-) -- Jamie