[Gllug] VM talk (was: Linux 2.4.10 is out with better VM)

[Christian Smith]

On Tue, 9 Oct 2001, Matt Amos wrote:

>personally, i would be very interested in seeing a talk on VM stuff, not
>necessarily about linux, maybe UVM and Mach could be covered as well. i
>dont think there would be time to cover it in detail, but maybe the
>salient points?

I was thinking along the lines of overview of MM hardware and how VM is
built on top, with examples from Linux, Mach/UVM/BSD and SysV. Nothing
majorly Linux specific, as Linux VM is such a mess.

Does anyone know what was covered in the last talk, or point me to a copy
of the presentation? The gllug site links to past meetings are broken.

>
>> > All a legacy of a VM system that was derived from the origional x86 model.
>> > In VM terms, Linux is where 4.3BSD was, which had a VM system based on the
>> > VAX, and generalised to try to make it 'portable' to other architectures.
>
>which is an advantage and a disadvantage. VM architecture is typically not
>only processor family dependant but frequently depends on the exact model
>and speed. to provide an optimised VM model the code must be as close to
>the hardware as possible. better algorithms such as UVM may help, but for
>performance theres nothing like severe specialisation.

>From Matt Dillon interview (http://www.osnews.com/story.php?news_id=153)
"I will admit to wanting to take a clue-bat to some of the people arguing
against Rik's VM work who simply do not understand the difference between
optimizing a few nanoseconds out of a routine that is rarely called verses
spending a few extra cpu cycles to choose the best pages to recycle in
order to avoid disk I/O that would cost tens of millions of cpu cycles
later on."

The x86 model is arguably optimal on x86 only, and then only when
resolving a page reference into the MMU, which is hardware based anyway. A
more general approach is almost always better, as it will apply to
tommorows super processors, whereas x86 model may not.

Much of Linux's VM problems at the moment are under heavy load, when the
kernel has to scan every processes page table to find candidates for page
eviction. Rik's VM work referenced above is based on a reverse mapped page
reference table, which would mean the kernel has only one entry per
physical page to scan when trying to evict pages.

If anyone wants to argue Matt's point above, compare FreeBSD (based on
BSD/Mach VM) with Linux (based on optimised for x86 VM) under heavy load.
I'd take FreeBSD every time. Remember, heavy load is where you actually
really NEED the optimisations. Theres no point saving the odd CPU cycle
here and there if a CPU is 99% idle. And under high memory load, the
biggest bottleneck is the disk anyway, so choosing the right pages for
swapping is vastly more important than how fast they were chosen. The
Linux problems are mainly the wrong pages being chosen.

>
>cya,
>
>matt
>
>
>

-- 
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
     X                           - AGAINST MS ATTACHMENTS
    / \


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug