<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/4/2017 9:08 AM, D. Jeff Dionne
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5D2BAA76-2DDF-4203-A711-D23006D39166@SE-Instruments.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>Excellent paper with real metrics wrt design decisions. Old
enough that the patents have expired: <a
href="ftp://ftp.cs.wisc.edu/pub/techreports/1995/TR1277.pdf"
moz-do-not-send="true">ftp://ftp.cs.wisc.edu/pub/techreports/1995/TR1277.pdf</a><br>
<br>
</div>
</blockquote>
<br>
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?<br>
<br>
I hadn't really thought of this.<br>
<br>
or, was there something else here I missed?...<br>
<br>
<br>
with the existing MMU interface, this would allow for a 64kB logical
superpage.<br>
* though, a possible tweak could be replacing 1kB and 1MB pages with
16kB and 4MB.<br>
* I guess it is probably an alternative to accepting a constant
stream of TLB misses as an inevitability.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:5D2BAA76-2DDF-4203-A711-D23006D39166@SE-Instruments.com">
<div>Cheers,
<div>J</div>
</div>
<div><br>
On Dec 4, 2017, at 09:01, BGB <<a
href="mailto:cr88192@gmail.com" moz-do-not-send="true">cr88192@gmail.com</a>>
wrote:<br>
<br>
</div>
<br>
</blockquote>
<br>
<blockquote type="cite"
cite="mid:5D2BAA76-2DDF-4203-A711-D23006D39166@SE-Instruments.com">
<blockquote type="cite">
<div><span>ASID and multiple page sizes:</span><br>
<span>* these are also features I was leaving out of my
attempt.</span><br>
<span>* basically, the complexity they would add didn't really
seem "worth it"</span><br>
<span>** a traditional page table layout effectively also
leave pages hard-wired at 4kB.</span><br>
<span>** if a TLB is both small and set associative, ASIDs
aren't likely to be terribly effective.</span><br>
<span>*** essentially, the TLB will likely have "forgotten" by
the time it gets back to the process in question.</span><br>
<span></span><br>
<span>my MMU prototypes thus far have looked like:</span><br>
<span>* between 16x4(64) or 64x4(256) entries</span><br>
<span>** basically 16 or 64 buckets but each bucket is 4-way
set-associative.</span><br>
<span>** IME, a smaller 2-way or 4-way lookup seems to better
than a bigger 1-way lookup.</span><br>
<span>** fully associative is expensive though, so I am not
doing this.</span><br>
<span>*** this could be more viable if the TLB were small,
say, 8 or 16 entries.</span><br>
<span>** I haven't yet settled on a final TLB size (still a
lot more testing is needed in this area).</span><br>
<span>*** my more recent design was using a 16x4 TLB.</span><br>
<span>*** sadly, the memory budget (for buffers/caches/...)
isn't particularly generous.</span><br>
<span>*** ( though, synthesis seems to start going a bit
berserk somewhat below the theoretical limits ).</span><br>
<span>* a single TLB was also shared for both code and data.</span><br>
<span></span><br>
</div>
</blockquote>
</blockquote>
<br>
</body>
</html>