[J-core] MMU-Design

[BGB]

On 12/4/2017 9:08 AM, D. Jeff Dionne wrote:
> Excellent paper with real metrics wrt design decisions.   Old enough 
> that the patents have expired: 
> ftp://ftp.cs.wisc.edu/pub/techreports/1995/TR1277.pdf
>

the paper is long, so skimmed a bit, but I guess an idea that I can 
gather from this is that larger pages can be useful, but used as a 
collection of smaller pages?

I hadn't really thought of this.

or, was there something else here I missed?...


with the existing MMU interface, this would allow for a 64kB logical 
superpage.
* though, a possible tweak could be replacing 1kB and 1MB pages with 
16kB and 4MB.
* I guess it is probably an alternative to accepting a constant stream 
of TLB misses as an inevitability.


> Cheers,
> J
>
> On Dec 4, 2017, at 09:01, BGB <cr88192 at gmail.com 
> <mailto:cr88192 at gmail.com>> wrote:
>
>

>> ASID and multiple page sizes:
>> * these are also features I was leaving out of my attempt.
>> * basically, the complexity they would add didn't really seem "worth it"
>> ** a traditional page table layout effectively also leave pages 
>> hard-wired at 4kB.
>> ** if a TLB is both small and set associative, ASIDs aren't likely to 
>> be terribly effective.
>> *** essentially, the TLB will likely have "forgotten" by the time it 
>> gets back to the process in question.
>>
>> my MMU prototypes thus far have looked like:
>> * between 16x4(64) or 64x4(256) entries
>> ** basically 16 or 64 buckets but each bucket is 4-way set-associative.
>> ** IME, a smaller 2-way or 4-way lookup seems to better than a bigger 
>> 1-way lookup.
>> ** fully associative is expensive though, so I am not doing this.
>> *** this could be more viable if the TLB were small, say, 8 or 16 
>> entries.
>> ** I haven't yet settled on a final TLB size (still a lot more 
>> testing is needed in this area).
>> *** my more recent design was using a 16x4 TLB.
>> *** sadly, the memory budget (for buffers/caches/...) isn't 
>> particularly generous.
>> *** ( though, synthesis seems to start going a bit berserk somewhat 
>> below the theoretical limits ).
>> * a single TLB was also shared for both code and data.
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20171204/49b1556c/attachment.html>