[Gllug] Random freezes

[Christian Smith]

Thought this'd stoke the flames...;)


On Fri, 28 Jan 2005, Nix wrote:

>On Fri, 28 Jan 2005, Christian Smith spake:
>> With sun4c, NetBSD handles the strange SPARC MMU much better than Linux
>> ever could
>
>That's a risky statement.


It's widely ackowledged that Linux sucks on sun4c. Check out:
http://www.netbsd.org/Ports/sparc/faq.html#sparclinux-sun4c
http://www.uwsg.iu.edu/hypermail/linux/kernel/0107.0/0003.html

The issues have not been fixed in the meantime, and probably never will
be.

>
>>            due to the fundamental weakness of Linux MM architecture.
>
>Fundamental weakness? It's grown from an i386-specific system into
>something that can now handle ~15 wildly disparate architectures (I
>think that count's right, although some of them have iffy libc support
>or wobbly maintenance), NUMA and shared-cache and
>partially-shared-cache, caches software-maintained and not, you name it.
>
>In fact, substantial revisions were made specifically to support SPARC.
>
>(Note that while several different MMUs are used on SPARC-class boxes,
>the UltraSPARC MMUs are recognisably related to (some of) the SPARC
>ones, and many of the same weird features are still needed (IIRC, the
>biggest being software-invalidated caches and the lovely instructions
>that let you look at address spaces `as if' you were running in some
>other protection domain; but it's several years since I looked at this
>last...)


Crikey, software invalidated cache is truly the spawn of satan.

>
>
>So what's NetBSD got that Linux hasn't in this area? Where's Linux's MM
>`fundamentally weak'? (And which MM do you mean? 2.0, 2.2, 2.4 <2.4.10,
>2.4.x >2.4.10, and 2.6 are really quite different from each other in
>a number of fundamental ways.)


The fact that you were asking for qualification on which version of the
Linux VM has the problem shows that it is not a particularly stable
abstraction.

It's based on a "generalised" page table model, with 3 levels of pages.
That works fine on machines with <=3 levels of page tables, but x86-64 has
4 levels in 64 bit mode, I believe. It works alright in TLB based MMUs,
such as MIPS and SPARC V9, but doesn't really fit for inverted page table
based architectures.

It has the same problems that BSD 4.3 had with their VAX based VM
architecture. The abstraction is wrong, and limits what can be done easily
with the overlying VM. BSD 4.4 tossed that all away, and started afresh
with the Mach VM/pmap, allowing more flexible memory management.

Page tables are largely a hardware notion. Linux page tables are
overloaded with swap information, for example, making them impossible to
page out or discard. Not an issue for memory laden modern desktop, but an
issue for embedded or small machines. And page table reuse could even be a
win on memory rich machines, due to increased cache utilisation, though I
guess it would not be a big win.

Mach/BSD pmap and SVR4 hat are much better MMU abstractions. Simple APIs
which hides *all* the details of the hardware MMU, on top of which truly
platform independent VM can be built. NetBSD had a completely new VM model
between 1.4 and 1.5 across all 12 CPU families then supported, possible
only because the VM model was completely MMU agnostic.

The fact that BSDs are often cited as better under high load is a function
of it's better VM architecture. Linux would do well to adopt a similar
seperation of VM policy and mechanism. Alas, it will not happen.


Christian

-- 
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
     X                           - AGAINST MS ATTACHMENTS
    / \
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug