Re: Tonight's tradeoff

Liste des GroupesRevenir à c arch 
Sujet : Re: Tonight's tradeoff
De : sfuld (at) *nospam* alumni.cmu.edu.invalid (Stephen Fuld)
Groupes : comp.arch
Date : 08. Mar 2024, 15:58:11
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <usf923$1a5sl$2@dont-email.me>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Mozilla Thunderbird
On 3/8/2024 6:24 AM, David W Schroth wrote:
On Tue, 5 Mar 2024 10:32:03 -0800, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:
 
On 3/5/2024 9:32 AM, MitchAlsup1 wrote:
Stephen Fuld wrote:
>
On 3/5/2024 7:37 AM, MitchAlsup1 wrote:
Robert Finch wrote:
>
Bigfoot pages are 1MB in size. That allows an entire 64GB address
range to be mapped with one page table. With larger memory systems a
larger page size is needed IMO. 64GB is 65,536 pages still when the
pages are 1MB in size. There is 32GB RAM in my machine today.
Tomorrow it will 64GB.
>
Above a certain point the added latency of filling/spilling a page to
DISK
that is 64KB in size rather than 4KB in size outweighs the gain in
the TLB.
>
Sure.  But the 4K size was first used when disk transfer rates were
about 3 MB/sec.  Today, they are many times that, even if you are
using a single physical hard disk.  RAID and SSD can make that even
larger.  I don't know what the "optimal" page size is, but it is
certainly larger than 4KB.
>
While the data transfer rates are far higher today, the disk latency has
not kept pace with CPU performance {SSD is different}.
>
Sure, but the latency is the same no matter what the transfer size is.
So the fact that latency improvements haven't kept pace is irrelevant to
the question of optimal page size.
>
>
The CPU went from 60ns (16 MHz: 360/67) to 200ps (5GHz) 300× !!
And from 5 cycles per instruction to 3 instruction per cycle 15×
for a combined gain of 4,500×
>
Disk latency may have gone down from 8ms to 3ms (sometimes 2ms for
smaller disks) 3×-4×
>
{{I consider 360/67 as the beginning of paging; although Multics may be
the beginning.}}
>
Agreed.
>
>
I, also, believe that 4KB pages are a bit small for a new architecture.
I chose 8KB for My 66000 more because it took 1 level out of the page
tables supporting 64-bit VAS, and also made the paging hierarchy more
easy to remember:: 8K, 8M, 8G, 8T, 8P, 8E is easier to remember than
4K, 2M, 1G, ½T, ¼P, ?E.
>
Fair enough.  When Unisys implemented paging in the 2200 Series in the
1990s, they chose 16K (approximately - exactly if you consider 36 equals
32!).
>
 Actually, we use 4 KiW
Yes.  For those too young to remember, on the 2200 series, one word is 36 bits.  Hence my comment about 4KW being 16 KB, if 36 equals 32.
(contained in 32 KiB) as the page size.
I presume this is a result of the emulated systems using 64 bits for each 36 bit word.  I was referring to the original implementation on native hardware.

I
don't remember spill/fill time being an issue.
Ahh!  That goes along with Anton's comment and contradicts Mitch's comments about disk times being a factor.  Since you were there and involved in the implementation, what were the considerations in choosing 4KW? Not that I am challenging it - I think it was probably the correct decision.  I just want to better understand the reasoning behind it.
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)

Date Sujet#  Auteur
8 Mar 24 o Re: Tonight's tradeoff1Stephen Fuld

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal