#
cd836f60 |
| 21-Jul-2024 |
Alan Cox <alc@FreeBSD.org> |
vm: Retire kmem_arena
It has simply been an alias for the kernel_arena for many years now. Enough time has passed to retire it. Any out-of-tree kernel modules that directly use kmem_arena should sw
vm: Retire kmem_arena
It has simply been an alias for the kernel_arena for many years now. Enough time has passed to retire it. Any out-of-tree kernel modules that directly use kmem_arena should switch to kernel_arena.
Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D46057
show more ...
|
Revision tags: release/14.1.0 |
|
#
7a79d066 |
| 09-Apr-2024 |
Bojan Novković <bnovkov@FreeBSD.org> |
vm: improve kstack_object pindex calculation to avoid pindex holes
This commit replaces the linear transformation of kernel virtual addresses to kstack_object pindex values with a non-linear scheme
vm: improve kstack_object pindex calculation to avoid pindex holes
This commit replaces the linear transformation of kernel virtual addresses to kstack_object pindex values with a non-linear scheme that circumvents physical memory fragmentation caused by kernel stack guard pages. The new mapping scheme is used to effectively "skip" guard pages and assign pindices for non-guard pages in a contiguous fashion.
The new allocation scheme requires that all default-sized kstack KVAs come from a separate, specially aligned region of the KVA space. For this to work, this commited introduces a dedicated per-domain kstack KVA arena used to allocate kernel stacks of default size. The behaviour on 32-bit platforms remains unchanged due to a significatly smaller KVA space.
Aside from fullfilling the requirements imposed by the new scheme, a separate kstack KVA arena facilitates superpage promotion in the rest of kernel and causes most kstacks to have guard pages at both ends.
Reviewed by: alc, kib, markj Tested by: markj Approved by: markj (mentor) Differential Revision: https://reviews.freebsd.org/D38852
show more ...
|
Revision tags: release/13.3.0 |
|
#
29363fb4 |
| 23-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove ancient SCCS tags.
Remove ancient SCCS tags from the tree, automated scripting, with two minor fixup to keep things compiling. All the common forms in the tree were removed with a perl s
sys: Remove ancient SCCS tags.
Remove ancient SCCS tags from the tree, automated scripting, with two minor fixup to keep things compiling. All the common forms in the tree were removed with a perl script.
Sponsored by: Netflix
show more ...
|
Revision tags: release/14.0.0 |
|
#
95ee2897 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0 |
|
#
e2515283 |
| 27-Aug-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
7dd979df |
| 17-Aug-2020 |
Mark Johnston <markj@FreeBSD.org> |
Remove the VM map zone.
Today, the zone is only used to allocate a trio of kernel maps: the kernel map itself, and the exec and pipe submaps. Maps for user processes are dynamically allocated but a
Remove the VM map zone.
Today, the zone is only used to allocate a trio of kernel maps: the kernel map itself, and the exec and pipe submaps. Maps for user processes are dynamically allocated but are embedded in the vmspace structure, which is allocated from its own zone. Make the aforementioned kernel maps statically allocated and get rid of the zone.
While here, remove a stale comment above vmspace_alloc() and change the names of locks initialized in vm_map_init() to match vmspace_zinit().
Reported by: alc Reviewed by: alc, kib MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26052
show more ...
|
Revision tags: release/11.4.0 |
|
#
f13fa9df |
| 26-Apr-2020 |
Mark Johnston <markj@FreeBSD.org> |
Use a single VM object for kernel stacks.
Previously we allocated a separate VM object for each kernel stack. However, fully constructed kernel stacks are cached by UMA, so there is no harm in using
Use a single VM object for kernel stacks.
Previously we allocated a separate VM object for each kernel stack. However, fully constructed kernel stacks are cached by UMA, so there is no harm in using a single global object for all stacks. This reduces memory consumption and makes it easier to define a memory allocation policy for kernel stack pages, with the aim of reducing physical memory fragmentation.
Add a global kstack_object, and use the stack KVA address to index into the object like we do with kernel_object.
Reviewed by: kib Tested by: pho Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D24473
show more ...
|
Revision tags: release/12.1.0, release/11.3.0 |
|
#
46b0292a |
| 16-Jan-2019 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Do not reserve KVA for paging bufs in vm_ksubmap_init(), since now they allocate it in pbuf_init(). This should have been done together with r343030.
|
Revision tags: release/12.0.0 |
|
#
01d4e214 |
| 05-Oct-2018 |
Glen Barber <gjb@FreeBSD.org> |
MFH r338661 through r339200.
Sponsored by: The FreeBSD Foundation
|
#
ce44d808 |
| 27-Sep-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r338731 through r338987.
|
#
969e147a |
| 20-Sep-2018 |
Mark Johnston <markj@FreeBSD.org> |
Ensure that imports into per-domain kmem arenas are KVA_QUANTUM-aligned.
The old code appears to assume that vmem_alloc() would import size-aligned KVA chunks from the parent kernel_arena, but vmem
Ensure that imports into per-domain kmem arenas are KVA_QUANTUM-aligned.
The old code appears to assume that vmem_alloc() would import size-aligned KVA chunks from the parent kernel_arena, but vmem doesn't provide this guarantee.
Also remove the unused global RWX arena and add comments explaining why we have per-domain arenas.
Reported by: alc Reviewed by: alc, kib (previous version) Approved by: re (gjb) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17249
show more ...
|
Revision tags: release/11.2.0 |
|
#
0766f278 |
| 13-Jun-2018 |
Jonathan T. Looney <jtl@FreeBSD.org> |
Make UMA and malloc(9) return non-executable memory in most cases.
Most kernel memory that is allocated after boot does not need to be executable. There are a few exceptions. For example, kernel m
Make UMA and malloc(9) return non-executable memory in most cases.
Most kernel memory that is allocated after boot does not need to be executable. There are a few exceptions. For example, kernel modules do need executable memory, but they don't use UMA or malloc(9). The BPF JIT compiler also needs executable memory and did use malloc(9) until r317072.
(Note that a side effect of r316767 was that the "small allocation" path in UMA on amd64 already returned non-executable memory. This meant that some calls to malloc(9) or the UMA zone(9) allocator could return executable memory, while others could return non-executable memory. This change makes the behavior consistent.)
This change makes malloc(9) return non-executable memory unless the new M_EXEC flag is specified. After this change, the UMA zone(9) allocator will always return non-executable memory, and a KASSERT will catch attempts to use the M_EXEC flag to allocate executable memory using uma_zalloc() or its variants.
Allocations that do need executable memory have various choices. They may use the M_EXEC flag to malloc(9), or they may use a different VM interfact to obtain executable pages.
Now that malloc(9) again allows executable allocations, this change also reverts most of r317072.
PR: 228927 Reviewed by: alc, kib, markj, jhb (previous version) Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D15691
show more ...
|
#
796df753 |
| 30-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
SPDX: Consider code from Carnegie-Mellon University.
Interesting cases, most likely from CMU Mach sources.
|
#
82725ba9 |
| 23-Nov-2017 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Merge ^/head r325999 through r326131.
|
#
51369649 |
| 20-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for
sys: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
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.
show more ...
|
Revision tags: release/10.4.0, release/11.1.0 |
|
#
348238db |
| 01-Mar-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r314420 through r314481.
|
#
fbbd9655 |
| 01-Mar-2017 |
Warner Losh <imp@FreeBSD.org> |
Renumber copyright clause 4
Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is
Renumber copyright clause 4
Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu> Pull Request: https://github.com/freebsd/freebsd/pull/96
show more ...
|
#
2b532af8 |
| 05-Jan-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r311314 through r311459.
|
#
ec492b13 |
| 05-Jan-2017 |
Mark Johnston <markj@FreeBSD.org> |
Add a small allocator for exec_map entries.
Upon each execve, we allocate a KVA range for use in copying data to the new image. Pages must be faulted into the range, and when the range is freed, the
Add a small allocator for exec_map entries.
Upon each execve, we allocate a KVA range for use in copying data to the new image. Pages must be faulted into the range, and when the range is freed, the backing pages are freed and their mappings are destroyed. This is a lot of needless overhead, and the exec_map management becomes a bottleneck when many CPUs are executing execve concurrently. Moreover, the number of available ranges is fixed at 16, which is insufficient on large systems and potentially excessive on 32-bit systems.
The new allocator reduces overhead by making exec_map allocations persistent. When a range is freed, pages backing the range are marked clean and made easy to reclaim. With this change, the exec_map is sized based on the number of CPUs.
Reviewed by: kib MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8921
show more ...
|
Revision tags: release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0 |
|
#
0bfd163f |
| 18-Oct-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r256722.
|
#
1ccca3b5 |
| 10-Oct-2013 |
Alan Somers <asomers@FreeBSD.org> |
IFC @256277
Approved by: ken (mentor)
|
Revision tags: release/9.2.0 |
|
#
ef90af83 |
| 20-Sep-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r255692
Comment out IA32_MISC_ENABLE MSR access - this doesn't exist on AMD. Need to sort out how arch-specific MSRs will be handled.
|
#
d1d01586 |
| 05-Sep-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head
|
#
46ed9e49 |
| 04-Sep-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r255209
|
#
8441d1e8 |
| 14-Aug-2013 |
Jeff Roberson <jeff@FreeBSD.org> |
- Add a statically allocated memguard arena since it is needed very early on. - Pass the appropriate flags to vmem_xalloc() when allocating space for the arena from kmem_arena.
Sponsored by:
- Add a statically allocated memguard arena since it is needed very early on. - Pass the appropriate flags to vmem_xalloc() when allocating space for the arena from kmem_arena.
Sponsored by: EMC / Isilon Storage Division
show more ...
|