MESI Caching work start (was Re: caching and userapi)

[Matthew Dillon]

:Matt, this is exactly the method propesed by Larry McVoy to avoid
:having 1000+ mutexes in a kernel: have a simple, non-mutexed kernel
:take care of each cpu and then manage to get a global page cache memory
:across them, with mmap fully working.
:
:Have a look at http://lwn.net/2001/1206/a/ccCluster.php3
:
:By the way, when dragonfly manages to work with it's internal
:ports system, can we rename you to 'Matt "Amiga Rules" Dillon'? ;)
:
:Greets, Antonio.

    Interesting.  That article is dated 4 Dec 2001.  I wonder if Larry
    has updated his thinking since then.  I also looked at the slides
    and flipped through the two papers mentioned.  He doesn't specifically
    mention MESI but it is obvious that he is angling for the same effect.

    The funny thing is that what Larry, and what I am proposing, is not hard
    to do.  The MESI (Modified Exclusive Shared Invalid) model has been around
    for ages and is the most common model used in SMP systems for L1/L2 
    interactions.  It's a very well known technology that even deals with the
    'cache' nature of the information (since an L1/L2 cache only represents
    a small portion of available system memory, things are constantly being
    thrown away).

    The only major difference between a hardware implementation and a software
    implementation is the fact that it is far more expensive to 'broadcast'
    certain cache state transitions to the other cpus in software.  If this
    is the only problem then I am certain the performance issue is solvable.

    I would call this sort of feature *CRITICAL* to DragonFly's future.

    -

    Or 'Matt "Son of Amiga" Dillon', complete with a bouncing baby ball
    logo :-0

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>