DragonFly kernel List (threaded) for 2003-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: MESI Caching work start (was Re: caching and userapi)
: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@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]