From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KzWIw-0007m1-L5 for qemu-devel@nongnu.org; Mon, 10 Nov 2008 07:55:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KzWIu-0007lm-GM for qemu-devel@nongnu.org; Mon, 10 Nov 2008 07:55:41 -0500 Received: from [199.232.76.173] (port=47507 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KzWIu-0007lj-Ck for qemu-devel@nongnu.org; Mon, 10 Nov 2008 07:55:40 -0500 Received: from rv-out-0708.google.com ([209.85.198.243]:21066) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KzWIt-0001y1-Ry for qemu-devel@nongnu.org; Mon, 10 Nov 2008 07:55:40 -0500 Received: by rv-out-0708.google.com with SMTP id f25so2365718rvb.22 for ; Mon, 10 Nov 2008 04:55:38 -0800 (PST) Message-ID: Date: Mon, 10 Nov 2008 13:55:38 +0100 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] [PATCH, v2] Rewrite mmap_find_vma() to work fine on 64-bit hosts with 32-bit targets In-Reply-To: <20081110080234.GA18267@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <20081110080234.GA18267@shareable.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org 2008/11/10 Jamie Lokier : > 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 :-) I was wondering the same, but I think binary search won't work: whenever you make a step greater than page size you risk having missed a free page closer to you. In the end you need to check all of them. The in-kernel allocator probably is in a better position to have a smart algorithm. Cheers