According to Lawrence D'Oliveiro <ldo@nz.invalid>:

On Thu, 27 Jun 2024 17:39:46 +0000, MitchAlsup1 wrote:

I did; TSS 360/67 CMU, and I did; both PL/C and PL/1.

Did you make much use of LOCATE-style I/O?

I also programmed on TSS and no. It had its own virtual access methods
with names like VISAM that were integrated with the pager.

I suppose if you were reading or writing a tape you might have used
QSAM with locate mode but I never did tape stuff.

On OS/360 people used locate mode all the time. If you declared your
PL/I variables with base pointers it was easy to use and it was faster
since it avoided buffer copies.

I think COBOL normally did locate mode I/O for sequential files unless
you used READ INTO or WRITE FROM verbs.

--
Regards,
John Levine, johnl@taugh.com, 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)

According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:

Virtual memory was pretty new technology at the time, and required a
disk or drum. The central idea of /360 was having the same ISA across
a wide range of machines, and virtual memory wasn't affordable at the
low end at the time, AFAICS.

But IIRC even low end S/360s required a disk, at least to IPL(boot)

Nope. They could IPL just fine from card or tape. You could run TOS on
a 16K machine that only had tapes. They also had BPS, which provided
card-only assembler, RPG and some utilities, but I do not get the
impression that was used much other than for debugging and
bootstrapping other stuff.

I believe that disk prices came down fast enough that nearly everyone
had a had a disk drive, even if they also put most of their data on
tapes.

--
Regards,
John Levine, johnl@taugh.com, 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)

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:

An application where one writes via mmap and others read
using stdio or read/write/pread/pwrite simulataneously
is poorly designed.

"An application"? I live in a world where all kinds of programs can
access the same files. How such a program works internally is often
not known to the designers of the others.

In practice your advice boils down to avoiding to write with mmap().

It's more like don't try to write shared files unless you know all of
the writers are using consistent locking. Squinting at the source code
for FreeBSD's stdio, it only flushes writes when it fills the buffer
or when it writes a \n character with the '\n' hard coded in the
source code. It doesn't lock at all other than between threads in the
same task.

You need at least as many locks and flushes to keep things in sync as
you would with mapped files.

In my experience, mmap is most often used when record-granularity
is required, rather than treating the mapped region as a
stream-of-bytes.

I usually mmap() the whole file.

Same here, although I have used mmap() to map a whole file as well as
for database record stuff.

* You have to extend the file length with a separate system call, and
then mmap() the new area, so you might just as well use write().

False economy. ftruncate is a single system call.

Yes, that's the one that extends the file length. ftruncate()
followed by mmap() are two system calls. And at some point you also
want to msync() (although not for each ftruncate).

Seems to me the sensible thing to do is to use ftruncate and mmap to
extend the file in large chunks, say several megabytes at a time, not
one block at a time. If you have too many system calls your chunks are
not big enough. I believe the file systems do what they do with write()
and only allocate disk blocks the first time you write to them so there
is little penalty for extending in large chunks.





--
Regards,
John Levine, johnl@taugh.com, 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 <johnl@taugh.com> writes:

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:

An application where one writes via mmap and others read
using stdio or read/write/pread/pwrite simulataneously
is poorly designed.

"An application"? I live in a world where all kinds of programs can
access the same files. How such a program works internally is often
not known to the designers of the others.

In practice your advice boils down to avoiding to write with mmap().

It's more like don't try to write shared files unless you know all of
the writers are using consistent locking. Squinting at the source code
for FreeBSD's stdio, it only flushes writes when it fills the buffer
or when it writes a \n character with the '\n' hard coded in the
source code. It doesn't lock at all other than between threads in the
same task.

You need at least as many locks and flushes to keep things in sync as
you would with mapped files.

In my experience, mmap is most often used when record-granularity
is required, rather than treating the mapped region as a
stream-of-bytes.

I usually mmap() the whole file.

I didn't say otherwise. I meant ccessing the data as records
(via e.g struct pointers) rather then treating the mmap region as a
stream of bytes and using stdio-type accesses.

Same here, although I have used mmap() to map a whole file as well as
for database record stuff.

* You have to extend the file length with a separate system call, and
then mmap() the new area, so you might just as well use write().

False economy. ftruncate is a single system call.

Yes, that's the one that extends the file length. ftruncate()
followed by mmap() are two system calls. And at some point you also
want to msync() (although not for each ftruncate).

Seems to me the sensible thing to do is to use ftruncate and mmap to
extend the file in large chunks, say several megabytes at a time, not
one block at a time. If you have too many system calls your chunks are
not big enough. I believe the file systems do what they do with write()
and only allocate disk blocks the first time you write to them so there
is little penalty for extending in large chunks.

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.

ftruncate to the final size at close.

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

According to MitchAlsup1 <mitchalsup@aol.com>:

Scott Lurndal wrote:

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.

Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address space

Every filesystem has a maximum file size. Exceed that and you'll get
an EFBIG error.

--
Regards,
John Levine, johnl@taugh.com, 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)

Scott Lurndal wrote:

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.

Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address space

ftruncate to the final size at close.

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

John Levine wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

Scott Lurndal wrote:

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.

Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address space

Every filesystem has a maximum file size. Exceed that and you'll get
an EFBIG error.

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.

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

On Sun, 30 Jun 2024 18:06:36 -0000 (UTC), John Levine wrote:

Squinting at the source code for FreeBSD's stdio, it only flushes writes
when it fills the buffer or when it writes a \n character with the '\n'
hard coded in the source code.

Both POSIX and C specs require this to be configurable <https://manpages.debian.org/3/setbuf.3.en.html>.

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

According to MitchAlsup1 <mitchalsup@aol.com>:

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.

Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address space

Every filesystem has a maximum file size. Exceed that and you'll get
an EFBIG error.

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.

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?

--
Regards,
John Levine, johnl@taugh.com, 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)

According to Lawrence D'Oliveiro <ldo@nz.invalid>:

On Mon, 1 Jul 2024 02:10:43 -0000 (UTC), John Levine wrote:

The goal here is to map a file into the address space.

What if you don’t know how big it’s going to be?

You might look at the answer to that question in a message I posted
earlier today. This isn't rocket science.

--
Regards,
John Levine, johnl@taugh.com, 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)

t appears that Lawrence D'Oliveiro <ldo@nz.invalid> said:

On Sun, 30 Jun 2024 18:06:36 -0000 (UTC), John Levine wrote:

Squinting at the source code for FreeBSD's stdio, it only flushes writes
when it fills the buffer or when it writes a \n character with the '\n'
hard coded in the source code.

Both POSIX and C specs require this to be configurable ><https://manpages.debian.org/3/setbuf.3.en.html>.

I looked at more of the code and it seems to do the right thing in
lower level routines. But the point stands, if you want to have
multiple programs writing into the same file, they all need to have
matching locking and buffering.
--
Regards,
John Levine, johnl@taugh.com, 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)

On Mon, 1 Jul 2024 02:10:43 -0000 (UTC), John Levine wrote:

The goal here is to map a file into the address space.

What if you don’t know how big it’s going to be?

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

On Mon, 1 Jul 2024 02:10:43 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

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.

Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address
space

Every filesystem has a maximum file size. Exceed that and you'll
get an EFBIG error.

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.

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?

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?

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

Michael S wrote:

On Mon, 1 Jul 2024 02:10:43 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

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.

Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address
space

Every filesystem has a maximum file size. Exceed that and you'll
get an EFBIG error.

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.

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?

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?

To answer this one has to use the proper verbology::

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

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

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

mitchalsup@aol.com (MitchAlsup1) writes:

Michael S wrote:

On Mon, 1 Jul 2024 02:10:43 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

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.

Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address >>>>>>space

Every filesystem has a maximum file size. Exceed that and you'll
get an EFBIG error.

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.

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?

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?

To answer this one has to use the proper verbology::

Half the virtual address space of x86-64 is 63-bits
Half the physical address space is as low as 38-bits and as high as
47-bits

And generally the address space usable by an application is
limited by the OS/user virtual address boundary (e.g. 2gb
or 3gb on 32-bit x86, and 2^55 for ARM64).

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

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

Michael S wrote:

On Mon, 1 Jul 2024 02:10:43 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

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.

Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address >>>>>space

Every filesystem has a maximum file size. Exceed that and you'll
get an EFBIG error.

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.

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?

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?

To answer this one has to use the proper verbology::

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:
• A logical processor uses 4-level paging if CR0.PG = 1, CR4.PAE = 1, IA32_EFER.LME = 1, and CR4.LA57 = 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.
•
A logical processor uses 5-level paging if CR0.PG = 1, CR4.PAE = 1, IA32_EFER.LME = 1, and CR4.LA57 = 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—all with the goal to create
confidential, isolated execution environments for virtual machines�
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�

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.
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 == 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.

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

On Tue, 02 Jul 2024 00:28:45 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

Michael S wrote:

On Mon, 1 Jul 2024 02:10:43 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

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.

Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address >>>>>>space

Every filesystem has a maximum file size. Exceed that and you'll
get an EFBIG error.

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.

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?

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?

To answer this one has to use the proper verbology::

Half the virtual address space of x86-64 is 63-bits
Half the physical address space is as low as 38-bits and as high as
47-bits

And generally the address space usable by an application is
limited by the OS/user virtual address boundary (e.g. 2gb
or 3gb on 32-bit x86, and 2^55 for ARM64).

2**49 (IIRC) on ARMv8-A and 2**56 on ARMv9-A is a architectural hardware
limit rather than OS limit.

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

Michael S <already5chosen@yahoo.com> writes:

On Tue, 02 Jul 2024 00:28:45 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

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

To answer this one has to use the proper verbology::

Half the virtual address space of x86-64 is 63-bits
Half the physical address space is as low as 38-bits and as high as
47-bits =20

=20
And generally the address space usable by an application is
limited by the OS/user virtual address boundary (e.g. 2gb
or 3gb on 32-bit x86, and 2^55 for ARM64).

2**49 (IIRC) on ARMv8-A and 2**56 on ARMv9-A is a architectural hardware >limit rather than OS limit.

Those define the number of supported address bits in a virtual
address (which can be as few as 16 bits if programmed in TCR_ELx).

bit 55 selects between the two halves of the virtual address space
(TTBR0_ELx, TTBR1_ELx) in EL0, EL1 and EL2+E2H, which is the OS limit.

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