Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: streams and file locks, ancient OS history, ARM is sort of
 channeling
Date: Tue, 2 Jul 2024 13:11:49 +0300
Organization: A noiseless patient Spider
Lines: 130
Message-ID: <20240702131149.00002f7c@yahoo.com>
References: <s7r87j1c3u6mim0db3ccbdvknvtjr4anu3@4ax.com>
	<9eb8f81dda97a8df903df255311cf8e9@www.novabbs.org>
	<v5snp7$1apd$1@gal.iecc.com>
	<7e40b7fc3fb42813e36a2dc31b486a29@www.novabbs.org>
	<v5t373$2kpm$1@gal.iecc.com>
	<20240701112303.0000285a@yahoo.com>
	<d59ff977d49f950020661ace6e067c4d@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 02 Jul 2024 12:11:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5fbca3f539c7d7fdf38abe2835a4f1fd";
	logging-data="1652684"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/7bMkhlXB5IMQzyjDoOsHw5aRooO2bqvY="
Cancel-Lock: sha1:wGTyjuPpze0lge0AheS/A6yDOYg=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 6932

On Mon, 1 Jul 2024 21:34:42 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> Michael S wrote:
>=20
> > On Mon, 1 Jul 2024 02:10:43 -0000 (UTC)
> > John Levine <johnl@taugh.com> wrote:
> > =20
> >> According to MitchAlsup1 <mitchalsup@aol.com>: =20
> >>>>>> In fact, you can ftruncate arbitrarily large at the start -
> >>>>>> backing sectors for the mapped pages will only be allocated
> >>>>>> when a page is referenced for the first time. =20
> >>>>>
> >>>>>Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? =C2=BD of the address
> >>>>>space =20
> >>>>
> >>>> Every filesystem has a maximum file size. Exceed that and you'll
> >>>> get an EFBIG error. =20
> >>>
> >>>Then it is not capable of ftruncate arbitrarily large in a
> >>>hardware's view of arbitrarily large which tends to be 1-bit
> >>>smaller than the largest container. =20
> >>
> >> The goal here is to map a file into the address space. What's your
> >> use case for mapping a file-like thing that is bigger than any
> >> real file and can't be written out to the disk?
> >> =20
> >
> > Consider that configurations in which maximal file size is bigger
> > than half of address space are quite common. And not just on 32-bit
> > HW.
> >
> > Of course, what is considered "half of address space" is not a very
> > simple question by itself. Take x86-64. Is its address space 2**64
> > or 2*48? Take aarch64. Is its address space 2**64 or 2**49? Or, may
> > be, 2**56? =20
>=20
> To answer this one has to use the proper verbology::
>=20
> Half the virtual address space of x86-64 is 63-bits

I am not sure.
New Intel Manual say:
4.5
4-LEVEL PAGING AND 5-LEVEL PAGING
Because the operation of 4-level paging and 5-level paging is very
similar, they are described together in this section. The following
items highlight the distinctions between the two paging modes:
=E2=80=A2 A logical processor uses 4-level paging if CR0.PG =3D 1, CR4.PAE =
=3D 1,
IA32_EFER.LME =3D 1, and CR4.LA57 =3D 0.
4-level paging translates 48-bit linear addresses to 52-bit physical
addresses.(1) Although 52 bits corresponds to 4 PBytes, linear
addresses are limited to 48 bits; at most 256 TBytes of linear-address
space may be accessed at any given time.
=E2=80=A2
A logical processor uses 5-level paging if CR0.PG =3D 1, CR4.PAE =3D 1,
IA32_EFER.LME =3D 1, and CR4.LA57 =3D 1.
5-level paging translates 57-bit linear addresses to 52-bit physical
addresses. Thus, 5-level paging supports a linear-address space
sufficient to access the entire physical-address space.

(1) - If MAXPHYADDR < 52, bits in the range 51:MAXPHYADDR will be 0 in
any physical address used by 4-level paging. (The corresponding bits
are reserved in the paging-structure entries.) See Section 4.1.4 for
how to determine MAXPHYADDR.

To me it sounds like 57-bit virtual address space rather than 64-bit.


Old Intel Manual says.
3.4.1
Logical Address Translation in IA-32e Mode
In IA-32e mode, an Intel 64 processor uses the steps described above to
translate a logical address to a linear address. In 64-bit mode, the
offset and base address of the segment are 64-bits instead of 32 bits.
The linear address format is also 64 bits wide and is subject to the
canonical form requirement.

4.1.1 Three Paging Modes
<snip>
64-bit mode. While this mode produces 64-bit linear addresses, the
processor ensures that bits 63:47 of such an address are identical.(1)
4-level paging does not use bits 63:48 of such addresses.
<snip>
(1) - Such an address is called canonical. Use of a non-canonical
linear address in 64-bit mode produces a general-protection exception
(#GP(0)); the processor does not attempt to translate non-canonical
linear addresses using 4-level paging.

To me it sounds like 48-bit virtual address space rather than 64-bit.

> Half the physical address space is as low as 38-bits and as high as
> 47-bits
> depending on the implementation (i.e., age)
>

Indeed for the very long time the limit was 47 bits, which in practice
meant that main memory address was at most 46 bits (64 TB).
But 4th gen AMD EPYC white paper claims 57 bit:

AMD SECURE NESTED PAGING (SEV-SNP)* introduced in 3rd Gen AMD EPYC
processors, builds on SEV and SEV-ES by adding strong encryption to
virtual machine nested page tables to help prevent attacks such as data
replay, memory remapping, and more=E2=80=94all with the goal to create
confidential, isolated execution environments for virtual machines=EF=BF=BD
With the 57-bit physical memory enabled by 4th Gen AMD EPYC processors,
we have increased the page table depth that can be encrypted to five
levels=EF=BF=BD

Considering that AMD uses the same 5-level paging tables as Intel
that, according to Intel, supports only 52 physical bits, I don't know
what to make of it.

Anyway, all this huge physical address spaces are predicated on success
of CXL-mem, which most likely would not happen.=20
With "normal" memory AMD EPYC4 can access at most 12 TB. Intel Sapphire
Rapids in 8S configuration can access 32 TB, but newer Emerald Rapids
supports at most 2 SMP sockets =3D=3D 8TB.
For more than decade it looks like big SMP is a dying breed. Only IBM z
is still growing # dies per SMP domain. The rest of them are on the
opposite trail - they could occasionally grow # of dies per package,
but # of packages per SMP domains is shrinking and the day when even
dual-socket SMP is abandoned by x86-64, ARM and POWER server vendors
appears rather close.

> This is one of those situations where the physical realm overrules the
> virtual realm.