#
cfb00e5a |
| 13-May-2011 |
Matthew D Fleming <mdf@FreeBSD.org> |
Move the ZERO_REGION_SIZE to a machine-dependent file, as on many architectures (i386, for example) the virtual memory space may be constrained enough that 2MB is a large chunk. Use 64K for arches o
Move the ZERO_REGION_SIZE to a machine-dependent file, as on many architectures (i386, for example) the virtual memory space may be constrained enough that 2MB is a large chunk. Use 64K for arches other than amd64 and ia64, with special handling for sparc64 due to differing hardware.
Also commit the comment changes to kmem_init_zero_region() that I missed due to not saving the file. (Darn the unfamiliar development environment).
Arch maintainers, please feel free to adjust ZERO_REGION_SIZE as you see fit.
Requested by: alc MFC after: 1 week MFC with: r221853
show more ...
|
#
9b4fcf85 |
| 18-Feb-2011 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@218816
|
Revision tags: release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0 |
|
#
50a57dfb |
| 09-Jan-2011 |
Konstantin Belousov <kib@FreeBSD.org> |
Move repeated MAXSLP definition from machine/vmparam.h to sys/vmmeter.h. Update the outdated comments describing MAXSLP and the process selection algorithm for swap out.
Comments wording and reviewe
Move repeated MAXSLP definition from machine/vmparam.h to sys/vmmeter.h. Update the outdated comments describing MAXSLP and the process selection algorithm for swap out.
Comments wording and reviewed by: alc
show more ...
|
#
6297a3d8 |
| 08-Jan-2011 |
Konstantin Belousov <kib@FreeBSD.org> |
Create shared (readonly) page. Each ABI may specify the use of page by setting SV_SHP flag and providing pointer to the vm object and mapping address. Provide simple allocator to carve space in the p
Create shared (readonly) page. Each ABI may specify the use of page by setting SV_SHP flag and providing pointer to the vm object and mapping address. Provide simple allocator to carve space in the page, tailored to put the code with alignment restrictions.
Enable shared page use for amd64, both native and 32bit FreeBSD binaries. Page is private mapped at the top of the user address space, moving a start of the stack one page down. Move signal trampoline code from the top of the stack to the shared page.
Reviewed by: alc
show more ...
|
#
0c21a60c |
| 05-Dec-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
svn+ssh://svn.freebsd.org/base/head@216199
|
#
2006fbc8 |
| 02-Dec-2010 |
Dimitry Andric <dim@FreeBSD.org> |
Sync: merge r215944 through r216132 from ^/head.
|
#
686b00d6 |
| 26-Nov-2010 |
Alan Cox <alc@FreeBSD.org> |
Make the size of the direct map easily configurable. Changing NDMPML4E now suffices.
Increase the size of the direct map to 1TB.
An earler version of this patch was tested by sbruno@.
|
#
6f3544cd |
| 26-Oct-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@214309
|
#
0b750af1 |
| 17-Sep-2010 |
Andriy Gapon <avg@FreeBSD.org> |
amd64: reduce VM_KMEM_SIZE_SCALE to 1 allowing kernel to use more memory
KVA space is abundant on amd64, so there is no reason to limit kernel map size to a fraction of available physical memory. I
amd64: reduce VM_KMEM_SIZE_SCALE to 1 allowing kernel to use more memory
KVA space is abundant on amd64, so there is no reason to limit kernel map size to a fraction of available physical memory. In fact, it could be larger than physical memory.
This should help with memory auto-tuning for ZFS and shouldn't affect other workloads. This should reduce number of circumstances for "kmem_map too small" panics, but probably won't eliminate them entirely due to potential kmem fragmentation.
In fact, you might want/need to limit maximum ARC size after this commit if you need to resrve more memory for applications.
This change was discussed on arch@ and nobody said "don't do it".
MFC after: 6 weeks
show more ...
|
#
b17f9ad2 |
| 16-Aug-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@211344
|
#
a3870a18 |
| 27-Jul-2010 |
John Baldwin <jhb@FreeBSD.org> |
Very rough first cut at NUMA support for the physical page allocator. For now it uses a very dumb first-touch allocation policy. This will change in the future. - Each architecture indicates the ma
Very rough first cut at NUMA support for the physical page allocator. For now it uses a very dumb first-touch allocation policy. This will change in the future. - Each architecture indicates the maximum number of supported memory domains via a new VM_NDOMAIN parameter in <machine/vmparam.h>. - Each cpu now has a PCPU_GET(domain) member to indicate the memory domain a CPU belongs to. Domain values are dense and numbered from 0. - When a platform supports multiple domains, the default freelist (VM_FREELIST_DEFAULT) is split up into N freelists, one for each domain. The MD code is required to populate an array of mem_affinity structures. Each entry in the array defines a range of memory (start and end) and a domain for the range. Multiple entries may be present for a single domain. The list is terminated by an entry where all fields are zero. This array of structures is used to split up phys_avail[] regions that fall in VM_FREELIST_DEFAULT into per-domain freelists. - Each memory domain has a separate lookup-array of freelists that is used when fulfulling a physical memory allocation. Right now the per-domain freelists are listed in a round-robin order for each domain. In the future a table such as the ACPI SLIT table may be used to order the per-domain lookup lists based on the penalty for each memory domain relative to a specific domain. The lookup lists may be examined via a new vm.phys.lookup_lists sysctl. - The first-touch policy is implemented by using PCPU_GET(domain) to pick a lookup list when allocating memory.
Reviewed by: alc
show more ...
|
Revision tags: release/8.1.0_cvs, release/8.1.0 |
|
#
9307d8bd |
| 08-May-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@207793
|
#
945f418a |
| 06-May-2010 |
Kirk McKusick <mckusick@FreeBSD.org> |
Final update to current version of head in preparation for reintegration.
|
#
2965a453 |
| 30-Apr-2010 |
Kip Macy <kmacy@FreeBSD.org> |
On Alan's advice, rather than do a wholesale conversion on a single architecture from page queue lock to a hashed array of page locks (based on a patch by Jeff Roberson), I've implemented page lock s
On Alan's advice, rather than do a wholesale conversion on a single architecture from page queue lock to a hashed array of page locks (based on a patch by Jeff Roberson), I've implemented page lock support in the MI code and have only moved vm_page's hold_count out from under page queue mutex to page lock. This changes pmap_extract_and_hold on all pmaps.
Supported by: Bitgravity Inc.
Discussed with: alc, jeffr, and kib
show more ...
|
Revision tags: release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0 |
|
#
10b3b545 |
| 17-Sep-2009 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Merge from head
|
#
2e370a5c |
| 26-May-2009 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
Merge from HEAD
|
#
b522d2c9 |
| 17-May-2009 |
Kip Macy <kmacy@FreeBSD.org> |
correct range in comment pointed out by alc
|
#
e1279022 |
| 17-May-2009 |
Kip Macy <kmacy@FreeBSD.org> |
update vm map comment
pointed out by Larry Rosenman
|
#
b6d82b1a |
| 16-May-2009 |
Kip Macy <kmacy@FreeBSD.org> |
Increase default kernel map to 512GB
I briefly discussed this with alc. It could lead to problems for greater than 64GB. However, that seems unlikely in practice.
|
Revision tags: release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0 |
|
#
8136b726 |
| 09-Jul-2008 |
Alan Cox <alc@FreeBSD.org> |
Eliminate pmap_growkernel()'s dependence on create_pagetables() preallocating page directory pages from VM_MIN_KERNEL_ADDRESS through the end of the kernel's bss. Specifically, the dependence was in
Eliminate pmap_growkernel()'s dependence on create_pagetables() preallocating page directory pages from VM_MIN_KERNEL_ADDRESS through the end of the kernel's bss. Specifically, the dependence was in pmap_growkernel()'s one- time initialization of kernel_vm_end, not in its main body. (I could not, however, resist the urge to optimize the main body.)
Reduce the number of preallocated page directory pages to just those needed to support NKPT page table pages. (In fact, this allows me to revert a couple of my earlier changes to create_pagetables().)
show more ...
|
#
13e00584 |
| 05-Jul-2008 |
Alan Cox <alc@FreeBSD.org> |
Increase the kernel map's size to 7GB, making room for a kmem map of size greater than 4GB. (Auto-sizing will set the ceiling on the kmem map size to 4.2GB.)
|
#
db0a9105 |
| 03-Jul-2008 |
Alan Cox <alc@FreeBSD.org> |
Increase the ceiling on the kmem map's size to 3.6GB. Also, define the ceiling as a fraction of the kernel map's size rather than an absolute quantity. Thus, scaling of the kmem map's size will be
Increase the ceiling on the kmem map's size to 3.6GB. Also, define the ceiling as a fraction of the kernel map's size rather than an absolute quantity. Thus, scaling of the kmem map's size will be automatic with changes to the kernel map's size.
show more ...
|
#
17e21388 |
| 30-Jun-2008 |
Alan Cox <alc@FreeBSD.org> |
Document the layout of the address space, borrowing heavily from http://lists.freebsd.org/pipermail/freebsd-amd64/2005-July/005578.html
|
#
ce3cb388 |
| 29-Jun-2008 |
Alan Cox <alc@FreeBSD.org> |
Strictly speaking, the definition of VM_MAX_KERNEL_ADDRESS is wrong. However, in practice, the error (currently) makes no difference because the computation performed by KVADDR() hides the error. T
Strictly speaking, the definition of VM_MAX_KERNEL_ADDRESS is wrong. However, in practice, the error (currently) makes no difference because the computation performed by KVADDR() hides the error. This revision fixes the error.
Also, eliminate a (now) unused definition.
show more ...
|
#
bd4328d3 |
| 23-Jun-2008 |
Alan Cox <alc@FreeBSD.org> |
Ensure that KERNBASE is no less than the virtual address -2GB.
|