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

[Les Till]

Christian Smith wrote:
> 
> 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.
> According to the Gllug Archives - The meeting was held in October 2000 and it
 was titled 'Linux memory management'. Mark Hemment gave the talk.
 Plenty of gen on VM to be found in the book 'Understanding the Linux
Kernel'
 Which reminds me I should start trying to read this again. 
> >
> >> > 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

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