[no subject]

@apollo.backplane.com> <20070112013508.GA32061@gnuppy.monkey.org>
From: Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: VKernel progress update - 9 Jan 2006
Date: Thu, 11 Jan 2007 17:53:56 -0800 (PST)
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:kernel@crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel@crater.dragonflybsd.org>
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 78
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1168567515 crater_reader.dragonflybsd.org 829 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:10430


:Yeah, heh, most of the initial interest in UML was for file systems
:development so that they didn't have to restart all of time, etc...
:
:KVM is a recent addition to the Linux kernel and I expect that to
:overtake Xen in a rather short amount of time since there's a lot of
:effort behind it using those virtualization mechanisms in AMD/Intel
:processors. MMU issues are a hell. I'm sorry I don't have an more
:specifics.
:
:	http://lwn.net/Articles/207875/
:
:This is different than your use for dfBSD VFS development. Congrads
:on VKernel BTW. :)
:
:bill

    Emulating the MMU is not fun, that is for sure.  What is a simple
    invlpg instruction on the real cpu has to be a system call on the
    virtual kernel that not only tells the real cpu to invalidate the
    page, but the real cpu ALSO must clean out the cached page table
    entries in the PMAP.  

    The modify bit is also not fun.  On a real system modifying a writable
    page just works and the hardware updates the page table entry for that
    page, setting the PG_M bit.  But since the virtual kernel's page
    tables are not under hardware control, the real kernel has to initially
    map writable pages read-only so it can take a fault when an attempt is
    made to write to one, then locate the virtual page table entry and set
    the VPTE_M bit in that entry.  Once that is done the real kernel can
    remap the page R+W.  But this also means that whenever the virtual
    kernel wants to clear the VPTE_M bit, it must tell the real kernel
    to reset the real PTE to take another fault if another write occurs.

    I would say about 70% of the reduced performance is due to the MMU,
    and 30% is due to the additional syscall overhead. 

    Real System:		(FORK)

	cd /usr/src/test/sysperf
	make /tmp/fork1
	/tmp/fork1
	fork/exit/wait:  1.510s 10000 loops = 150.963uS/loop

    Under a virtual kernel:	(FORK)

	fork/exit/wait: 21.875s 10000 loops = 2187.536uS/loop

    Real System:		(GETUID)
	
	cd /usr/src/test/sysperf
	make /tmp/sc1	(after replacing the read(0,...) with getuid())
	/tmp/sc1
	getuid()  0.938s 3559400 loops =  0.263uS/loop

    Under a virtual kernel:	(FORK)

	getuid()  0.976s 305300 loops =  3.198uS/loop


    A 2ms fork isn't the end of the world, but I sure would love to be able
    to make those MMU faults go faster.

    The 3uS getuid() system call is due to the emulated user process context
    having to fault into the real kernel and then the real kernel having
    to switch contexts back to the virtual kernel and copyout the register
    frame.

    I don't have numbers for page table faults, but at least for those
    the real kernel doesn't have to drop into the virtual kernel unless
    the emualted page table is missing the page table entry for the VA.
    (the real kernel handles setting the VPTE_M bit itself).  I still have
    some work to do there today and tomorrow that might improve performance
    a bit.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>