According to Scott Lurndal <[email protected]>:

ARM64 (ARMv8) architecturally supports 4k, 16k and 64k.

S/370 had 2K or 4K pages grouped into 64K or 1M segment tables. By the time it became S/390 it was just 4K pages and 1M segment tables, in a 31 bit address spave.

In zSeries there are multiple 2G regions consisting of 1M segments and 4K pages.
A segment can optionally be mapped as a single unit, in effect a 1M page.

These days it doesn't make much sense to have pages smaller than 4K since that's the block size on most disks. I can believe that with today's giant memories and bloated programs larger than 4K pages would work better.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

These days it doesn't make much sense to have pages smaller than 4K since >that's the block size on most disks.

Two block devices bought less than a year ago:

Disk model: KINGSTON SEDC2000BM8960G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk model: WD Blue SN580 2TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Anton Ertl <[email protected]>:

John Levine <[email protected]> writes:

These days it doesn't make much sense to have pages smaller than 4K since >>that's the block size on most disks.

Two block devices bought less than a year ago:

SSDs often let you do 512 byte reads and writes for backward compatibility even though the physical block size is much larger.

Wikipedia tells us all about it:

https://en.wikipedia.org/wiki/Advanced_Format#512_emulation_(512e)

Disk model: KINGSTON SEDC2000BM8960G

Says here the block size of the 480GB version is 16K, so I'd assume the 960GB is
the same:

https://www.techpowerup.com/ssd-specs/kingston-dc2000b-480-gb.d2166

Disk model: WD Blue SN580 2TB

I can't find anything on its internal structure but I see the vendor's random read/write benchmarks all use 4K blocks so that's probably the internal block size.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> writes:

SSDs often let you do 512 byte reads and writes for backward compatibility even
though the physical block size is much larger.

Yes. But if the argument had any merit that 512B is a good page size
because it avoids having to transfer 8, 16, or 32 sectors at a time,
it would still have merit, because the interface still shows 512B
sectors. In 1985, 1986 and 1992 the common HDDs of the time had
actual 512B sectors, so if that argument had any merit, the i386
(1985), MIPS R2000 (1986), SPARC (1986), and Alpha (1992) should have
been introduced with 512B pages, but they actually were introduced
with 4KB (386, MIPS, SPARC) and 8KB (Alpha) pages.

Disk model: WD Blue SN580 2TB

I can't find anything on its internal structure but I see the vendor's random >read/write benchmarks all use 4K blocks so that's probably the internal block >size.

https://www.techpowerup.com/ssd-specs/western-digital-sn580-2-tb.d1542

claims

|Page Size: 16 KB
|Block Size: 1344 Pages

I assume that the "Block size" means the size of an erase block.
Where does the number 1344 come from? My guess is that it has to do
with:

|Type: TLC
|Technology: 112-layer

3*112*4=1344

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/15/2025 10:09 PM, Anton Ertl wrote:

John Levine <[email protected]> writes:

SSDs often let you do 512 byte reads and writes for backward compatibility even
though the physical block size is much larger.

Yes. But if the argument had any merit that 512B is a good page size
because it avoids having to transfer 8, 16, or 32 sectors at a time,
it would still have merit, because the interface still shows 512B
sectors.

I don't think anyone has argued for 512B page sizes. There are two
issues that are perhaps being conflated. One is whether it would be
better if page sizes were increased from the current typical 4K to 16K.
The other is about changing the size of blocks on disks (both hard disks
and SSDs) from 512 bytes to 4K bytes.



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Anton Ertl <[email protected]>:

John Levine <[email protected]> writes:

SSDs often let you do 512 byte reads and writes for backward compatibility even
though the physical block size is much larger.

Yes. But if the argument had any merit that 512B is a good page size
because it avoids having to transfer 8, 16, or 32 sectors at a time,
it would still have merit, because the interface still shows 512B
sectors.

I think we're agreeing that even in the early 1980s a 512 byte page was
too small. They certainly couldn't have made it any smaller, but they
should have made it larger.

S/370 was a decade before that and its pages were 2K or 4M. The KI-10,
the first PDP-10 with paging, had 2K pages in 1972. Its pager was based
on BBN's add-on pager for TENEX, built in 1970 also with 2K pages.





--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <[email protected]> wrote:

According to Anton Ertl <[email protected]>:

John Levine <[email protected]> writes:

SSDs often let you do 512 byte reads and writes for backward compatibility even
though the physical block size is much larger.

Yes. But if the argument had any merit that 512B is a good page size >>because it avoids having to transfer 8, 16, or 32 sectors at a time,
it would still have merit, because the interface still shows 512B
sectors.

I think we're agreeing that even in the early 1980s a 512 byte page was
too small. They certainly couldn't have made it any smaller, but they
should have made it larger.

S/370 was a decade before that and its pages were 2K or 4M. The KI-10,
the first PDP-10 with paging, had 2K pages in 1972. Its pager was based
on BBN's add-on pager for TENEX, built in 1970 also with 2K pages.

Several posts above I wrote:

: I think that in 1979 VAX 512 bytes page was close to optimal.
: Namely, IIUC smallest supported configuration was 128 KB RAM.
: That gives 256 pages, enough for sophisticated system with
: fine-grained access control.

Note that 360 has optional page protection used only for access
control. In 370 era they had legacy of 2k or 4k pages, and
AFAICS IBM was mainly aiming at bigger machines, so they
were not so worried about fragmentation. PDP-11 experience
possibly contributed to using smaller pages for VAX.

Microprocessors were designed with different constraints, which
led to bigger pages. But VAX apparently could afford resonably
large TLB and due VMS structure gain was bigger than for other
OS-es.

And little correction: VAX architecture handbook is dated 1977,
so actually decision about page size had to be made at least
in 1977 and possibly earlier.

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Waldek Hebisch <[email protected]>:

S/370 was a decade before that and its pages were 2K or 4K. The KI-10,
the first PDP-10 with paging, had 2K pages in 1972. Its pager was based
on BBN's add-on pager for TENEX, built in 1970 also with 2K pages.

...

Note that 360 has optional page protection used only for access
control. In 370 era they had legacy of 2k or 4k pages, and
AFAICS IBM was mainly aiming at bigger machines, so they
were not so worried about fragmentation.

I don't think so. The smallest 370s were 370/115 with 64K to 192K of
RAM, 370/125 with 96K to 256K, both with paging hardware and running
DOS/VS. The 115 was shipped in 1973, the 125 in 1972.

PDP-11 experience possibly contributed to using smaller pages for VAX.

The PDP-11's pages were 8K which were too big to be used as pages so
we used them as a single block for swapping. When I was at Yale I did
a hack that mapped the 32K display memory for a bitmap terminal into
the high half of the process' data space but that left too little room
for regular data so we addressed the display memory a different way that
didn't use up address spavce.

Microprocessors were designed with different constraints, which
led to bigger pages. But VAX apparently could afford resonably
large TLB and due VMS structure gain was bigger than for other
OS-es.

I can only guess what their thinking was, but I can tell you that
at the time the 512 byte pages seemed oddly small.

And little correction: VAX architecture handbook is dated 1977,
so actually decision about page size had to be made at least
in 1977 and possibly earlier.

The VAX design started in 1976, well after IBM had shipped those
low end 370s with tiny memories and 2K pages.
--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)