Differential D49913

Make UVA LA57 opt-int
Needs ReviewPublic
Actions

Authored by kib on Sat, Apr 19, 10:59 AM.

Details

Reviewers

markj

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

kib created this revision.Sat, Apr 19, 10:59 AM

Herald added a subscriber: imp. · View Herald TranscriptSat, Apr 19, 10:59 AM

kib requested review of this revision.Sat, Apr 19, 10:59 AM

markj added inline comments.Sat, Apr 19, 2:46 PM

sys/amd64/amd64/pmap.c
434	Maybe default_la48_uva or something like that? The tunable affects only userspace mappings AFAIK.
437
usr.bin/elfctl/elfctl.c
71	Probably the elfctl man page should document the interaction between la48 and la57?

Rename the sysctl, remove _NOFETCH flag, update the sysctl description.
Add some note about la57 + la48 flags in elfctl(1).

Herald added a subscriber: ziaee. · View Herald TranscriptSat, Apr 19, 3:02 PM

More words in elfctl(1).

kib mentioned this in D49931: arch.7: Add a section describing the user address space.Sun, Apr 20, 6:36 PM

This seems ok. I still think the approach is inferior to using the mmap() hint or a new flag. A process, especially a language runtime, could legitimately load some library which wants to use the full LA57 address space even when other components in the process do not support LA57. General-purpose applications do not get much benefit from the extra address bits, and with this approach, the extra bits are inaccessible to libraries unless the binary is specially marked. It is probably fine for appliance vendors at least.

sys/amd64/amd64/pmap.c
434	I would add some comment here that the default value is needed in order to preserve compatibility with some userspace programs.
usr.bin/elfctl/elfctl.1
99
106
107
111
usr.bin/elfctl/elfctl.c
70
72

kbowling added a subscriber: kbowling.Mon, Apr 21, 11:21 PM

In D49913#1139036, @markj wrote:

This seems ok. I still think the approach is inferior to using the mmap() hint or a new flag. A process, especially a language runtime, could legitimately load some library which wants to use the full LA57 address space even when other components in the process do not support LA57. General-purpose applications do not get much benefit from the extra address bits, and with this approach, the extra bits are inaccessible to libraries unless the binary is specially marked. It is probably fine for appliance vendors at least.

I personally think that such library (which is fine with LA57) but the main process is not is too unlikely to exist. It needs to be too hermetic in the aspect of never leaking the memory addresses outside the internals of the library. The overall practice is to assume that there is only one allocator in the process, and whatever memory you have, it can be free()-ed. This is engraved even into C++ and Rust. Of course GC-ed runtime are not such, but C libraries loaded into them with FFI are.

Editing for comments and user strings.