|
Revision tags: release/13.4.0-p5, release/13.5.0-p1, release/14.2.0-p3, release/13.5.0, release/14.2.0-p2, release/14.1.0-p8, release/13.4.0-p4, release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3, release/14.2.0, release/13.4.0, release/14.1.0, release/13.3.0, release/14.0.0 |
|
| #
2ff63af9 |
| 16-Aug-2023 |
Warner Losh <[email protected]> |
sys: Remove $FreeBSD$: one-line .h pattern
Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/
|
|
Revision tags: release/13.2.0 |
|
| #
9cb6ba29 |
| 21-Jan-2023 |
Andrew Gallatin <[email protected]> |
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 <[email protected]> |
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 |
|
| #
a69511db |
| 13-Jun-2022 |
Brooks Davis <[email protected]> |
amd64: -m32 support for machine/vmparam.h
Install the i386 vmparam.h under /usr/include/i386 on amd64 and include when targeting i386.
Reviewed by: jhb, imp
|
|
Revision tags: release/13.1.0, release/12.3.0 |
|
| #
90d4da62 |
| 17-Nov-2021 |
Mitchell Horne <[email protected]> |
amd64: provide PHYS_IN_DMAP() and VIRT_IN_DMAP()
It is useful for quickly checking an address against the DMAP region. These definitions exist already on arm64 and riscv.
Reviewed by: kib, markj MF
amd64: provide PHYS_IN_DMAP() and VIRT_IN_DMAP()
It is useful for quickly checking an address against the DMAP region. These definitions exist already on arm64 and riscv.
Reviewed by: kib, markj MFC after: 3 days Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D32962
show more ...
|
| #
89786088 |
| 10-Aug-2021 |
Mark Johnston <[email protected]> |
amd64: Populate the KMSAN shadow maps and integrate with the VM
- During boot, allocate PDP pages for the shadow maps. The region above KERNBASE is currently not shadowed. - Create a dummy shadow
amd64: Populate the KMSAN shadow maps and integrate with the VM
- During boot, allocate PDP pages for the shadow maps. The region above KERNBASE is currently not shadowed. - Create a dummy shadow for the vm page array. For now, this array is not protected by the shadow map to help reduce kernel memory usage. - Grow shadows when growing the kernel map. - Increase the default kernel stack size when KMSAN is enabled. As with KASAN, sanitizer instrumentation appears to create stack frames large enough that the default value is not sufficient. - Disable UMA's use of the direct map when KMSAN is configured. KMSAN cannot validate the direct map. - Disable unmapped I/O when KMSAN configured. - Lower the limit on paging buffers when KMSAN is configured. Each buffer has a static MAXPHYS-sized allocation of KVA, which in turn eats 2*MAXPHYS of space in the shadow map.
Reviewed by: alc, kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D31295
show more ...
|
| #
f95f780e |
| 10-Aug-2021 |
Mark Johnston <[email protected]> |
amd64: Define KVA regions for KMSAN shadow maps
KMSAN requires two shadow maps, each one-to-one with the kernel map. Allocate regions of the kernels PML4 page for them. Add functions to create mapp
amd64: Define KVA regions for KMSAN shadow maps
KMSAN requires two shadow maps, each one-to-one with the kernel map. Allocate regions of the kernels PML4 page for them. Add functions to create mappings in the shadow map regions, these will be used by the KMSAN runtime.
Reviewed by: alc, kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D31295
show more ...
|
| #
e18380e3 |
| 10-Jul-2021 |
Konstantin Belousov <[email protected]> |
amd64: do not assume that kernel is loaded at 2M physical
Allow any 2M aligned contiguous location below 4G for the staging area location. It should still be mapped by loader at KERNBASE.
The assu
amd64: do not assume that kernel is loaded at 2M physical
Allow any 2M aligned contiguous location below 4G for the staging area location. It should still be mapped by loader at KERNBASE.
The assumption kernel makes about loader->kernel handoff with regard to the MMU programming are explicitly listed at the beginning of hammer_time(), where kernphys is calculated. Now kernphys is the variable instead of symbol designating the physical address.
Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31121
show more ...
|
| #
6faf45b3 |
| 13-Apr-2021 |
Mark Johnston <[email protected]> |
amd64: Implement a KASAN shadow map
The idea behind KASAN is to use a region of memory to track the validity of buffers in the kernel map. This region is the shadow map. The compiler inserts calls
amd64: Implement a KASAN shadow map
The idea behind KASAN is to use a region of memory to track the validity of buffers in the kernel map. This region is the shadow map. The compiler inserts calls to the KASAN runtime for every emitted load and store, and the runtime uses the shadow map to decide whether the access is valid. Various kernel allocators call kasan_mark() to update the shadow map.
Since the shadow map tracks only accesses to the kernel map, accesses to other kernel maps are not validated by KASAN. UMA_MD_SMALL_ALLOC is disabled when KASAN is configured to reduce usage of the direct map. Currently we have no mechanism to completely eliminate uses of the direct map, so KASAN's coverage is not comprehensive.
The shadow map uses one byte per eight bytes in the kernel map. In pmap_bootstrap() we create an initial set of page tables for the kernel and preloaded data.
When pmap_growkernel() is called, we call kasan_shadow_map() to extend the shadow map. kasan_shadow_map() uses pmap_kasan_enter() to allocate memory for the shadow region and map it.
Reviewed by: kib MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D29417
show more ...
|
|
Revision tags: release/13.0.0 |
|
| #
fd2ef8ef |
| 25-Nov-2020 |
Maxim Sobolev <[email protected]> |
Unobfuscate "KERNLOAD" parameter on amd64. This change lines-up amd64 with the i386 and the rest of supported architectures by defining KERNLOAD in the vmparam.h and getting rid of magic constant in
Unobfuscate "KERNLOAD" parameter on amd64. This change lines-up amd64 with the i386 and the rest of supported architectures by defining KERNLOAD in the vmparam.h and getting rid of magic constant in the linker script, which albeit documented via comment but isn't programmatically accessible at a compile time.
Use KERNLOAD to eliminate another (matching) magic constant 100 lines down inside unremarkable TU "copy.c" 3 levels deep in the EFI loader tree.
Reviewed by: markj Approved by: markj MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D27355
show more ...
|
|
Revision tags: release/12.2.0 |
|
| #
78257765 |
| 23-Sep-2020 |
Mark Johnston <[email protected]> |
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 |
| 21-Sep-2020 |
D Scott Phillips <[email protected]> |
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 ...
|
| #
543769bf |
| 01-Sep-2020 |
Mateusz Guzik <[email protected]> |
amd64: clean up empty lines in .c and .h files
|
| #
9ce875d9 |
| 23-Aug-2020 |
Konstantin Belousov <[email protected]> |
amd64 pmap: LA57 AKA 5-level paging
Since LA57 was moved to the main SDM document with revision 072, it seems that we should have a support for it, and silicons are coming.
This patch makes pmap su
amd64 pmap: LA57 AKA 5-level paging
Since LA57 was moved to the main SDM document with revision 072, it seems that we should have a support for it, and silicons are coming.
This patch makes pmap support both LA48 and LA57 hardware. The selection of page table level is done at startup, kernel always receives control from loader with 4-level paging. It is not clear how UEFI spec would adapt LA57, for instance it could hand out control in LA57 mode sometimes.
To switch from LA48 to LA57 requires turning off long mode, requesting LA57 in CR4, then re-entering long mode. This is somewhat delicate and done in pmap_bootstrap_la57(). AP startup in LA57 mode is much easier, we only need to toggle a bit in CR4 and load right value in CR3.
I decided to not change kernel map for now. Single PML5 entry is created that points to the existing kernel_pml4 (KML4Phys) page, and a pml5 entry to create our recursive mapping for vtopte()/vtopde(). This decision is motivated by the fact that we cannot overcommit for KVA, so large space there is unusable until machines start providing wider physical memory addressing. Another reason is that I do not want to break our fragile autotuning, so the KVA expansion is not included into this first step. Nice side effect is that minidumps are compatible.
On the other hand, (very) large address space is definitely immediately useful for some userspace applications.
For userspace, numbering of pte entries (or page table pages) is always done for 5-level structures even if we operate in 4-level mode. The pmap_is_la57() function is added to report the mode of the specified pmap, this is done not to allow simultaneous 4-/5-levels (which is not allowed by hw), but to accomodate for EPT which has separate level control and in principle might not allow 5-leve EPT despite x86 paging supports it. Anyway, it does not seems critical to have 5-level EPT support now.
Tested by: pho (LA48 hardware) Reviewed by: alc Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D25273
show more ...
|
|
Revision tags: release/11.4.0, release/12.1.0 |
|
| #
f97bf604 |
| 03-Sep-2019 |
Mark Johnston <[email protected]> |
Fix some nits in pmap_page_array_startup().
- Use ptoa() instead of the archaic ctob(). - Use pagezero() to zero a PDP page. - Remove PA_MIN_ADDRESS, orphaned by r351742. - Remove unneeded parens an
Fix some nits in pmap_page_array_startup().
- Use ptoa() instead of the archaic ctob(). - Use pagezero() to zero a PDP page. - Remove PA_MIN_ADDRESS, orphaned by r351742. - Remove unneeded parens and an unnecessary control flow statement.
Reported by: alc Reviewed by: alc, kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21495
show more ...
|
| #
9d75f0dc |
| 03-Sep-2019 |
Mark Johnston <[email protected]> |
Map the vm_page array into KVA on amd64.
r351198 allows the kernel to use domain-local memory to back the vm_page array (up to 2MB boundaries) and reserves a separate PML4 entry for that purpose. O
Map the vm_page array into KVA on amd64.
r351198 allows the kernel to use domain-local memory to back the vm_page array (up to 2MB boundaries) and reserves a separate PML4 entry for that purpose. One consequence of that change is that the vm_page array is no longer present in minidumps, which only adds pages mapped above VM_MIN_KERNEL_ADDRESS.
To avoid the friction caused by having kernel data structures mapped below VM_MIN_KERNEL_ADDRESS, map the vm_page array starting at VM_MIN_KERNEL_ADDRESS instead of using a dedicated PML4 entry.
Reviewed by: kib Discussed with: jeff Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21491
show more ...
|
| #
3e5e1b51 |
| 18-Aug-2019 |
Jeff Roberson <[email protected]> |
Allocate amd64's page array using pages and page directory pages from the NUMA domain that the pages describe. Patch original from gallatin.
Reviewed by: kib Tested by: pho Sponsored by: Netflix Di
Allocate amd64's page array using pages and page directory pages from the NUMA domain that the pages describe. Patch original from gallatin.
Reviewed by: kib Tested by: pho Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D21252
show more ...
|
|
Revision tags: release/11.3.0, release/12.0.0 |
|
| #
2fd0c8e7 |
| 16-Oct-2018 |
Konstantin Belousov <[email protected]> |
Provide pmap_large_map() KPI on amd64.
The KPI allows to map very large contigous physical memory regions into KVA, which are not covered by DMAP.
I see both with QEMU and with some real hardware s
Provide pmap_large_map() KPI on amd64.
The KPI allows to map very large contigous physical memory regions into KVA, which are not covered by DMAP.
I see both with QEMU and with some real hardware started shipping, the regions for NVDIMMs might be very far apart from the normal RAM, and we expect that at least initial users of NVDIMM could install very large amount of such memory. IMO it is not reasonable to extend DMAP to cover that far-away regions both because it could overflow existing 4T window for DMAP in KVA, and because it costs in page table pages allocations, for gap and for possibly unused NV RAM.
Also, KPI provides some special functionality for fast cache flushing based on the knowledge of the NVRAM mapping use.
Reviewed by: alc, markj Sponsored by: The FreeBSD Foundation Approved by: re (gjb) MFC after: 1 week Differential revision: https://reviews.freebsd.org/D17070
show more ...
|
| #
67d33338 |
| 27-Jul-2018 |
Warner Losh <[email protected]> |
Rename VM_FREELIST_ISADMA to VM_FREELIST_LOWMEM.
There's no differene between VM_FREELIST_ISADMA and VM_FREELIST_LOWMEM except for the default boundary (16MB on x86 and 256MB on MIPS, but they are o
Rename VM_FREELIST_ISADMA to VM_FREELIST_LOWMEM.
There's no differene between VM_FREELIST_ISADMA and VM_FREELIST_LOWMEM except for the default boundary (16MB on x86 and 256MB on MIPS, but they are otherwise the same). We don't need both for any system we support (there were some really old ARC systems that did have ISA/EISA bus, but we never ran on them and they are too old to ever grow support for).
Differential Review: https://reviews.freebsd.org/D16290
show more ...
|
|
Revision tags: release/11.2.0 |
|
| #
5cd29d0f |
| 24-Apr-2018 |
Mark Johnston <[email protected]> |
Improve VM page queue scalability.
Currently both the page lock and a page queue lock must be held in order to enqueue, dequeue or requeue a page in a given page queue. The queue locks are a scalabi
Improve VM page queue scalability.
Currently both the page lock and a page queue lock must be held in order to enqueue, dequeue or requeue a page in a given page queue. The queue locks are a scalability bottleneck in many workloads. This change reduces page queue lock contention by batching queue operations. To detangle the page and page queue locks, per-CPU batch queues are used to reference pages with pending queue operations. The requested operation is encoded in the page's aflags field with the page lock held, after which the page is enqueued for a deferred batch operation. Page queue scans are similarly optimized to minimize the amount of work performed with a page queue lock held.
Reviewed by: kib, jeff (previous versions) Tested by: pho Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D14893
show more ...
|
| #
9a8196ce |
| 19-Jan-2018 |
Nathan Whitehorn <[email protected]> |
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 ...
|
| #
df57947f |
| 18-Nov-2017 |
Pedro F. Giffuni <[email protected]> |
spdx: initial adoption of licensing ID tags.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensou
spdx: initial adoption of licensing ID tags.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point.
Initially, only tag files that use BSD 4-Clause "Original" license.
RelNotes: yes Differential Revision: https://reviews.freebsd.org/D13133
show more ...
|
|
Revision tags: release/10.4.0, release/11.1.0 |
|
| #
43af5860 |
| 17-May-2017 |
Edward Tomasz Napierala <[email protected]> |
Bump default MAXTSIZ (kern.maxtsiz) from 128MB to 32GB. The old limit prevents one from running eg clang built with debug; the new one is arbitrary (equal to MAXDSIZ) and... well, should be quite fut
Bump default MAXTSIZ (kern.maxtsiz) from 128MB to 32GB. The old limit prevents one from running eg clang built with debug; the new one is arbitrary (equal to MAXDSIZ) and... well, should be quite future-proof.
Same fix might be applicable to other 64 bit architectures; I'll ask their respective maintainers to make sure it won't break anything.
Reviewed by: kib MFC after: 2 weeks Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D10758
show more ...
|
|
Revision tags: release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0 |
|
| #
966272ca |
| 08-Jun-2015 |
Alan Cox <[email protected]> |
Retire VM_FREEPOOL_CACHE as the next step in eliminating PG_CACHE pages.
Differential Revision: https://reviews.freebsd.org/D2712 Reviewed by: kib Sponsored by: EMC / Isilon Storage Division
|
| #
b5243bd4 |
| 12-Jan-2015 |
Konstantin Belousov <[email protected]> |
Revert r276600: PHYS_TO_DMAP_RAW() and DMAP_TO_PHYS_RAW() are no longer used, remove them.
Reviewed by: alc Sponsored by: The FreeBSD Foundation MFC after: 1 week
|