#
0a44b8a5 |
| 03-May-2024 |
Bojan Novković <bnovkov@FreeBSD.org> |
vm: Simplify startup page dumping conditional
This commit introduces the MINIDUMP_STARTUP_PAGE_TRACKING symbol and uses it to simplify several instances of a complex preprocessor conditional for add
vm: Simplify startup page dumping conditional
This commit introduces the MINIDUMP_STARTUP_PAGE_TRACKING symbol and uses it to simplify several instances of a complex preprocessor conditional for adding pages allocated when bootstraping the kernel to minidumps.
Reviewed by: markj, mhorne Approved by: markj (mentor) Differential Revision: https://reviews.freebsd.org/D45085
show more ...
|
#
da76d349 |
| 03-May-2024 |
Bojan Novković <bnovkov@FreeBSD.org> |
uma: Deduplicate uma_small_alloc
This commit refactors the UMA small alloc code and removes most UMA machine-dependent code. The existing machine-dependent uma_small_alloc code is almost identical a
uma: Deduplicate uma_small_alloc
This commit refactors the UMA small alloc code and removes most UMA machine-dependent code. The existing machine-dependent uma_small_alloc code is almost identical across all architectures, except for powerpc where using the direct map addresses involved extra steps in some cases.
The MI/MD split was replaced by a default uma_small_alloc implementation that can be overridden by architecture-specific code by defining the UMA_MD_SMALL_ALLOC symbol. Furthermore, UMA_USE_DMAP was introduced to replace most UMA_MD_SMALL_ALLOC uses.
Reviewed by: markj, kib Approved by: markj (mentor) Differential Revision: https://reviews.freebsd.org/D45084
show more ...
|
Revision tags: release/13.3.0, release/14.0.0 |
|
#
2ff63af9 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .h pattern
Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/
|
Revision tags: release/13.2.0 |
|
#
9cb6ba29 |
| 21-Jan-2023 |
Andrew Gallatin <gallatin@FreeBSD.org> |
vm: centralize VM_BATCHQUEUE_SIZE definition
Remove the platform-specific definitions of VM_BATCHQUEUE_SIZE for amd64 and powerpc64, and instead treat all 64-bit platforms identically. This has the
vm: centralize VM_BATCHQUEUE_SIZE definition
Remove the platform-specific definitions of VM_BATCHQUEUE_SIZE for amd64 and powerpc64, and instead treat all 64-bit platforms identically. This has the effect of increasing the arm64 and riscv VM_BATCHQUEUE_SIZE to match that of other platforms.
Reviewed by: jhb, markj Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D37707
show more ...
|
#
1cac76c9 |
| 14-Dec-2022 |
Andrew Gallatin <gallatin@FreeBSD.org> |
vm: reduce lock contention when processing vm batchqueues
Rather than waiting until the batchqueue is full to acquire the lock & process the queue, we now start trying to acquire the lock using tryl
vm: reduce lock contention when processing vm batchqueues
Rather than waiting until the batchqueue is full to acquire the lock & process the queue, we now start trying to acquire the lock using trylocks when the batchqueue is 1/2 full. This removes almost all contention on the vm pagequeue mutex for for our busy sendfile() based web workload. It also greadly reduces the amount of time a network driver ithread remains blocked on a mutex, and eliminates some packet drops under heavy load.
So that the system does not loose the benefit of processing large batchqueues, I've doubled the size of the batchqueues. This way, when there is no contention, we process the same batch size as before.
This has been run for several months on a busy Netflix server, as well as on my personal desktop.
Reviewed by: markj Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D37305
show more ...
|
Revision tags: release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0 |
|
#
e2d6c417 |
| 06-Nov-2020 |
Leandro Lupori <luporl@FreeBSD.org> |
Implement superpages for PowerPC64 (HPT)
This change adds support for transparent superpages for PowerPC64 systems using Hashed Page Tables (HPT). All pmap operations are supported.
The changes wer
Implement superpages for PowerPC64 (HPT)
This change adds support for transparent superpages for PowerPC64 systems using Hashed Page Tables (HPT). All pmap operations are supported.
The changes were inspired by RISC-V implementation of superpages, by @markj (r344106), but heavily adapted to fit PPC64 HPT architecture and existing MMU OEA64 code.
While these changes are not better tested, superpages support is disabled by default. To enable it, use vm.pmap.superpages_enabled=1.
In this initial implementation, when superpages are disabled, system performance stays at the same level as without these changes. When superpages are enabled, buildworld time increases a bit (~2%). However, for workloads that put a heavy pressure on the TLB the performance boost is much bigger (see HPC Challenge and pgbench on D25237).
Reviewed by: jhibbits Sponsored by: Eldorado Research Institute (eldorado.org.br) Differential Revision: https://reviews.freebsd.org/D25237
show more ...
|
Revision tags: release/12.2.0 |
|
#
78257765 |
| 23-Sep-2020 |
Mark Johnston <markj@FreeBSD.org> |
Add a vmparam.h constant indicating pmap support for large pages.
Enable SHM_LARGEPAGE support on arm64.
Reviewed by: alc, kib Sponsored by: Juniper Networks, Inc., Klara, Inc. Differential Revisio
Add a vmparam.h constant indicating pmap support for large pages.
Enable SHM_LARGEPAGE support on arm64.
Reviewed by: alc, kib Sponsored by: Juniper Networks, Inc., Klara, Inc. Differential Revision: https://reviews.freebsd.org/D26467
show more ...
|
#
ab041f71 |
| 22-Sep-2020 |
D Scott Phillips <scottph@FreeBSD.org> |
Move vm_page_dump bitset array definition to MI code
These definitions were repeated by all architectures, with small variations. Consolidate the common definitons in machine independent code and us
Move vm_page_dump bitset array definition to MI code
These definitions were repeated by all architectures, with small variations. Consolidate the common definitons in machine independent code and use bitset(9) macros for manipulation. Many opportunities for deduplication remain in the machine dependent minidump logic. The only intended functional change is increasing the bit index type to vm_pindex_t, allowing the indexing of pages with address of 8 TiB and greater.
Reviewed by: kib, markj Approved by: scottl (implicit) MFC after: 1 week Sponsored by: Ampere Computing, Inc. Differential Revision: https://reviews.freebsd.org/D26129
show more ...
|
Revision tags: release/11.4.0 |
|
#
65bbba25 |
| 11-May-2020 |
Justin Hibbits <jhibbits@FreeBSD.org> |
powerpc64: Implement Radix MMU for POWER9 CPUs
Summary: POWER9 supports two MMU formats: traditional hashed page tables, and Radix page tables, similar to what's presesnt on most other architectures
powerpc64: Implement Radix MMU for POWER9 CPUs
Summary: POWER9 supports two MMU formats: traditional hashed page tables, and Radix page tables, similar to what's presesnt on most other architectures. The PowerISA also specifies a process table -- a table of page table pointers-- which on the POWER9 is only available with the Radix MMU, so we can take advantage of it with the Radix MMU driver.
Written by Matt Macy.
Differential Revision: https://reviews.freebsd.org/D19516
show more ...
|
#
dd8775a1 |
| 11-Apr-2020 |
Justin Hibbits <jhibbits@FreeBSD.org> |
powerpc/booke: Change Book-E 64-bit pmap to 4-level table
Summary: The existing page table is fraught with errors, since it creates a hole in the address space bits. Fix this by taking a cue from t
powerpc/booke: Change Book-E 64-bit pmap to 4-level table
Summary: The existing page table is fraught with errors, since it creates a hole in the address space bits. Fix this by taking a cue from the POWER9 radix pmap, and make the page table 4 levels, 52 bits.
Reviewed by: bdragon Differential Revision: https://reviews.freebsd.org/D24220
show more ...
|
#
caef3e12 |
| 07-Dec-2019 |
Justin Hibbits <jhibbits@FreeBSD.org> |
powerpc/pmap: NUMA-ize vm_page_array on powerpc
Summary: This matches r351198 from amd64. This only applies to AIM64 and Book-E. On AIM64 it short-circuits with one domain, to behave similar to exi
powerpc/pmap: NUMA-ize vm_page_array on powerpc
Summary: This matches r351198 from amd64. This only applies to AIM64 and Book-E. On AIM64 it short-circuits with one domain, to behave similar to existing. Otherwise it will allocate 16MB huge pages to hold the page array, across all NUMA domains. On the first domain it will shift the page array base up, to "upper-align" the page array in that domain, so as to reduce the number of pages from the next domain appearing in this domain. After the first domain, subsequent domains will be allocated in full 16MB pages, until the final domain, which can be short. This means some inner domains may have pages accounted in earlier domains.
On Book-E the page array is setup at MMU bootstrap time so that it's always mapped in TLB1, on both 32-bit and 64-bit. This reduces the TLB0 overhead for touching the vm_page_array, which reduces up to one TLB miss per array access.
Since page_range (vm_page_startup()) is no longer used on Book-E but is on 32-bit AIM, mark the variable as potentially unused, rather than using a nasty #if defined() list.
Reviewed by: luporl Differential Revision: https://reviews.freebsd.org/D21449
show more ...
|
Revision tags: release/12.1.0 |
|
#
6793e5b2 |
| 20-Aug-2019 |
Justin Hibbits <jhibbits@FreeBSD.org> |
powerpc: Link Book-E kernels at the same address as AIM kernels
Summary: Reduce the diff between AIM and Book-E even more. This also cleans up vmparam.h significantly.
Reviewed by: luporl Differen
powerpc: Link Book-E kernels at the same address as AIM kernels
Summary: Reduce the diff between AIM and Book-E even more. This also cleans up vmparam.h significantly.
Reviewed by: luporl Differential Revision: https://reviews.freebsd.org/D21301
show more ...
|
#
21943937 |
| 16-Aug-2019 |
Jeff Roberson <jeff@FreeBSD.org> |
Move phys_avail definition into MI code. It is consumed in the MI layer and doing so adds more flexibility with less redundant code.
Reviewed by: jhb, markj, kib Sponsored by: Netflix Differential
Move phys_avail definition into MI code. It is consumed in the MI layer and doing so adds more flexibility with less redundant code.
Reviewed by: jhb, markj, kib Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D21250
show more ...
|
#
141a0ab0 |
| 15-Aug-2019 |
Justin Hibbits <jhibbits@FreeBSD.org> |
powerpc/pmap: Enable UMA_MD_SMALL_ALLOC for 64-bit booke
The only thing blocking UMA_MD_SMALL_ALLOC from working on 64-bit booke powerpc was a missing check in pmap_kextract(). Adding DMAP handling
powerpc/pmap: Enable UMA_MD_SMALL_ALLOC for 64-bit booke
The only thing blocking UMA_MD_SMALL_ALLOC from working on 64-bit booke powerpc was a missing check in pmap_kextract(). Adding DMAP handling into pmap_kextract(), we can now use UMA_MD_SMALL_ALLOC. This should improve performance and stability a bit, since DMAP is always mapped in TLB1, so this relieves pressure on TLB0.
MFC after: 3 weeks
show more ...
|
Revision tags: release/11.3.0 |
|
#
45b33e80 |
| 13-Dec-2018 |
Justin Hibbits <jhibbits@FreeBSD.org> |
powerpc/booke: Change KERNBASE to be physical load address
Previous commits have made VM_MIN_KERNEL_ADDRESS its own separate entity, and rebased the kernel around that address instead of KERNBASE.
powerpc/booke: Change KERNBASE to be physical load address
Previous commits have made VM_MIN_KERNEL_ADDRESS its own separate entity, and rebased the kernel around that address instead of KERNBASE. This commit pulls the trigger to rebase KERNBASE to a physical load address. The eventual goal is to align the address with the AIM KERNBASE, but at this time that's not an option.
Currently a Book-E kernel must be loaded on a 64MB boundary, due to size issues. The common load address is at the 64MB mark (0x04000000), so simply make that the default KERNBASE.
As of this commit, Book-E kernels can be loaded and booted with ubldr.
MFC after: 3 weeks
show more ...
|
#
67350cb5 |
| 09-Dec-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r340918 through r341763.
|
Revision tags: release/12.0.0 |
|
#
8f69e36d |
| 28-Nov-2018 |
Justin Hibbits <jhibbits@FreeBSD.org> |
powerpc: Don't include KERNBASE in genassym, it's unnecessary
A related future change, which changes KERNBASE for Book-E for some reason causes a "KERNBASE redefined" error with assym.inc, even thou
powerpc: Don't include KERNBASE in genassym, it's unnecessary
A related future change, which changes KERNBASE for Book-E for some reason causes a "KERNBASE redefined" error with assym.inc, even though it only changed the value of KERNBASE and nothing else. Since machine/vmparam.h is already included in booke/locore.S, and the requisite guards are already in place for properly handling KERNBASE in vmparam.h, just remove it from genassym, and include vmparam.h in the AIM locore files.
show more ...
|
#
24c3112f |
| 28-Nov-2018 |
Justin Hibbits <jhibbits@FreeBSD.org> |
powerpc: Fix the powerpc64 build post-r341102
VM_MIN_KERNEL_ADDRESS is now used in locore.S, but the UL suffix isn't permitted in .S files.
|
Revision tags: release/11.2.0 |
|
#
3254c39f |
| 01-Jun-2018 |
Justin Hibbits <jhibbits@FreeBSD.org> |
Increase powerpc64 KVA from ~7.25GB to 32GB
This will let us use much more KVA for ZFS ARC where needed. This may be incresed in the future if memory requirements increase.
Discussed with: nwhiteh
Increase powerpc64 KVA from ~7.25GB to 32GB
This will let us use much more KVA for ZFS ARC where needed. This may be incresed in the future if memory requirements increase.
Discussed with: nwhitehorn
show more ...
|
#
9f5b999a |
| 03-Apr-2018 |
Justin Hibbits <jhibbits@FreeBSD.org> |
Add support for a pmap direct map for 64-bit Book-E
As with AIM64, map the DMAP at the beginning of the fourth "quadrant" of memory, and move the KERNBASE to the the start of KVA.
Eventually we may
Add support for a pmap direct map for 64-bit Book-E
As with AIM64, map the DMAP at the beginning of the fourth "quadrant" of memory, and move the KERNBASE to the the start of KVA.
Eventually we may run the kernel out of the DMAP, but for now, continue booting as it has been.
show more ...
|
#
f9edb09d |
| 07-Mar-2018 |
Nathan Whitehorn <nwhitehorn@FreeBSD.org> |
Move the powerpc64 direct map base address from zero to high memory. This accomplishes a few things: - Makes NULL an invalid address in the kernel, which is useful for catching bugs. - Lays groundw
Move the powerpc64 direct map base address from zero to high memory. This accomplishes a few things: - Makes NULL an invalid address in the kernel, which is useful for catching bugs. - Lays groundwork for radix-tree translation on POWER9, which requires the direct map be at high memory. - Similarly lays groundwork for a direct map on 64-bit Book-E.
The new base address is chosen as the base of the fourth radix quadrant (the minimum kernel address in this translation mode) and because all supported CPUs ignore at least the first two bits of addresses in real mode, allowing direct-map addresses to be used in real-mode handlers. This is required by Linux and is part of the architecture standard starting in POWER ISA 3, so can be relied upon.
Reviewed by: jhibbits, Breno Leitao Differential Revision: D14499
show more ...
|
#
1a55e1d0 |
| 23-Jan-2018 |
Justin Hibbits <jhibbits@FreeBSD.org> |
Fix 64-bit booke kernel builds after the ldscript changes
Commits r326203 and r326978 broke 64-bit booke kernels by introducing a 1MB zero-pad between the ELF header and the start of the kernel. Th
Fix 64-bit booke kernel builds after the ldscript changes
Commits r326203 and r326978 broke 64-bit booke kernels by introducing a 1MB zero-pad between the ELF header and the start of the kernel. This didn't cause a build failure, but caused kernels to need to be loaded into memory 1MB lower, which could easily break scripts expecting previous behavior. This change matches the similar change made to AIM in r327358.
show more ...
|
#
9a8196ce |
| 19-Jan-2018 |
Nathan Whitehorn <nwhitehorn@FreeBSD.org> |
Remove SFBUF_OPTIONAL_DIRECT_MAP and such hacks, replacing them across the kernel by PHYS_TO_DMAP() as previously present on amd64, arm64, riscv, and powerpc64. This introduces a new MI macro (PMAP_H
Remove SFBUF_OPTIONAL_DIRECT_MAP and such hacks, replacing them across the kernel by PHYS_TO_DMAP() as previously present on amd64, arm64, riscv, and powerpc64. This introduces a new MI macro (PMAP_HAS_DMAP) that can be evaluated at runtime to determine if the architecture has a direct map; if it does not (or does) unconditionally and PMAP_HAS_DMAP is either 0 or 1, the compiler can remove the conditional logic.
As part of this, implement PHYS_TO_DMAP() on sparc64 and mips64, which had similar things but spelled differently. 32-bit MIPS has a partial direct-map that maps poorly to this concept and is unchanged.
Reviewed by: kib Suggestions from: marius, alc, kib Runtime tested on: amd64, powerpc64, powerpc, mips64
show more ...
|
#
68b9c019 |
| 14-Jan-2018 |
Nathan Whitehorn <nwhitehorn@FreeBSD.org> |
Document places we assume that physical memory is direct-mapped at zero by using a new macro PHYS_TO_DMAP, which deliberately has the same name as the equivalent macro on amd64. This also sets the st
Document places we assume that physical memory is direct-mapped at zero by using a new macro PHYS_TO_DMAP, which deliberately has the same name as the equivalent macro on amd64. This also sets the stage for moving the direct map to another base address.
show more ...
|
#
4b49587c |
| 06-Jan-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r327341 through r327623.
|