Page MenuHomeFreeBSD

Enable largepage support for arm64.
ClosedPublic

Authored by markj on Sep 17 2020, 4:35 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 8 2024, 2:57 PM
Unknown Object (File)
Jan 11 2024, 12:59 AM
Unknown Object (File)
Jan 4 2024, 6:58 PM
Unknown Object (File)
Dec 20 2023, 6:09 AM
Unknown Object (File)
Nov 7 2023, 12:54 AM
Unknown Object (File)
Oct 5 2023, 11:53 PM
Unknown Object (File)
Aug 1 2023, 9:42 PM
Unknown Object (File)
Aug 1 2023, 9:41 PM

Details

Summary
  • Use a vmparam.h constant to indicate support for non-transparent largepage mappings. Use it in the shm code.
  • Enable on arm64.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Sep 17 2020, 4:35 PM

I did not do it this way because my feel was that requires asserts in other pmap_enter() that PMAP_ENTER_LARGEPAGE is not set. It might be fine as is.

In D26467#589425, @kib wrote:

I did not do it this way because my feel was that requires asserts in other pmap_enter() that PMAP_ENTER_LARGEPAGE is not set. It might be fine as is.

Why does the current scheme not require such assertions? I don't mind adding them to this diff, or simply extending the ifdef in kern_shm_open2(). I just prefer having a central place to indicate PMAP_ENTER_LARGEPAGE support.

In D26467#589425, @kib wrote:

I did not do it this way because my feel was that requires asserts in other pmap_enter() that PMAP_ENTER_LARGEPAGE is not set. It might be fine as is.

Why does the current scheme not require such assertions? I don't mind adding them to this diff, or simply extending the ifdef in kern_shm_open2(). I just prefer having a central place to indicate PMAP_ENTER_LARGEPAGE support.

I am not advocating keeping the current scheme, but for me its advantage was that there is simple place where the support for LARGEPAGE is specified per-arch. With PMAP_HAS_LARGEPAGE I need to inspect all <arch>/include/vmparam.h.

If switching to this scheme, we should provide a pattern for pmap_enter() where somebody copying current implementation to a new architecture clearly see that the flag is handled or not. My scheme makes it correct without any action from the porter.

In D26467#589671, @kib wrote:
In D26467#589425, @kib wrote:

I did not do it this way because my feel was that requires asserts in other pmap_enter() that PMAP_ENTER_LARGEPAGE is not set. It might be fine as is.

Why does the current scheme not require such assertions? I don't mind adding them to this diff, or simply extending the ifdef in kern_shm_open2(). I just prefer having a central place to indicate PMAP_ENTER_LARGEPAGE support.

I am not advocating keeping the current scheme, but for me its advantage was that there is simple place where the support for LARGEPAGE is specified per-arch. With PMAP_HAS_LARGEPAGE I need to inspect all <arch>/include/vmparam.h.

If switching to this scheme, we should provide a pattern for pmap_enter() where somebody copying current implementation to a new architecture clearly see that the flag is handled or not. My scheme makes it correct without any action from the porter.

How about we just assert PMAP_HAS_LARGEPAGES == 1 in the bdry_idx != 0 case in vm_fault_populate()? Then, if a porter defines a new arch without PMAP_ENTER_LARGEPAGE support but defines PMAP_HAS_LARGEPAGES == 1, it will be easily found by regression tests.

How about we just assert PMAP_HAS_LARGEPAGES == 1 in the bdry_idx != 0 case in vm_fault_populate()? Then, if a porter defines a new arch without PMAP_ENTER_LARGEPAGE support but defines PMAP_HAS_LARGEPAGES == 1, it will be easily found by regression tests.

Fine with me.

Assert PMAP_HAS_LARGEPAGES in vm_fault_populate().

This revision is now accepted and ready to land.Sep 22 2020, 2:16 PM