From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JNYev-0008EX-Ar for qemu-devel@nongnu.org; Fri, 08 Feb 2008 14:13:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JNYet-0008E6-HK for qemu-devel@nongnu.org; Fri, 08 Feb 2008 14:13:12 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JNYet-0008E3-Fu for qemu-devel@nongnu.org; Fri, 08 Feb 2008 14:13:11 -0500 Received: from mu-out-0910.google.com ([209.85.134.190]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JNYet-0000aN-2j for qemu-devel@nongnu.org; Fri, 08 Feb 2008 14:13:11 -0500 Received: by mu-out-0910.google.com with SMTP id w8so3257238mue.4 for ; Fri, 08 Feb 2008 11:13:10 -0800 (PST) Message-ID: Date: Fri, 8 Feb 2008 21:13:09 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] Kernel memory allocation debugging with Qemu In-Reply-To: <200802081855.05779.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200802081855.05779.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On 2/8/08, Paul Brook wrote: > > The patch takes a half of the memory and slows down the system. I > > think Qemu could be used instead. A channel (IO/MMIO) is created > > between the memory allocator in target kernel and Qemu running in the > > host. Memory allocator tells the allocated area to Qemu using the > > channel. Qemu changes the physical memory mapping for the area to > > special memory that will report any reads before writes back to > > allocator. Writes change the memory back to standard RAM. The > > performance would be comparable to Qemu in general and host kernel + > > Qemu only take a few MB of the memory. The system would be directly > > usable for other OSes as well. > > The qemu implementation isn't actually any more space efficient than the > in-kernel implementation. You still need the same amount of bookkeeping ram. > In both cases it should be possible to reduce the overhead from 1/2 to 1/9 by > using a bitmask rather than whole bytes. Qemu would not track all memory, only the regions that kmalloc() have given to other kernel that have not yet been written to. > Performance is a less clear. A qemu implementation probably causes less > relative slowdown than an in-kernel implementation. However it's still going > to be significantly slower than normal qemu. Remember that any checked > access is going to have to go through the slow case in the TLB lookup. Any > optimizations that are applicable to one implementation can probably also be > applied to the other. Again, we are not trapping all accesses. The fast case should be used for most kernel accesses and all of userland. > Given qemu is significantly slower to start with, and depending on the > overhead of taking the page fault, it might not end up much better overall. A > KVM implementation would most likely be slower than the in-kernel. > > That said it may be an interesting thing to play with. In practice it's > probably most useful to generate an interrupt and report back to the guest > OS, rather than having qemu reports faults directly. The access could happen when the interrupts are disabled, so a buffer should be needed. The accesses could also be written to a block device seen by both Qemu and the kernel, or appear to arrive from a fake network device.