summaryrefslogtreecommitdiffstats
path: root/sys/amd64/include/vmparam.h
Commit message (Collapse)AuthorAgeFilesLines
* MFC r318398:trasz2017-06-061-1/+1
| | | | | | | | | | | 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. Approved by: re (kib)
* Retire VM_FREEPOOL_CACHE as the next step in eliminating PG_CACHE pages.alc2015-06-081-3/+2
| | | | | | Differential Revision: https://reviews.freebsd.org/D2712 Reviewed by: kib Sponsored by: EMC / Isilon Storage Division
* Revert r276600: PHYS_TO_DMAP_RAW() and DMAP_TO_PHYS_RAW() are nokib2015-01-121-4/+2
| | | | | | | | longer used, remove them. Reviewed by: alc Sponsored by: The FreeBSD Foundation MFC after: 1 week
* For /dev/mem and /dev/kmem accesses, avoid asserting that addresseskib2015-01-031-2/+4
| | | | | | | are within direct map. We want to return error instead of panicing. PR: 194995 Sponsored by: The FreeBSD Foundation
* The physical memory allocator supports the use of distinct free lists foralc2014-12-311-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | managing pages from different address ranges. Generally speaking, this feature is used to increase the likelihood that physical pages are available that can meet special DMA requirements or can be accessed through a limited-coverage direct mapping (e.g., MIPS). However, prior to this change, the configuration of the free lists was static, i.e., it was determined at compile time. Consequentally, free lists could be created for address ranges that held no actual pages, for example, on 32-bit MIPS- based systems with 512 MB or less of physical memory. This change makes the creation of the free lists dynamic, i.e., it is based on the available physical memory at boot time. On 64-bit x86-based systems with 64 GB or more of physical memory, create free lists for managing pages with physical addresses below 4 GB. This change is to address reported problems with initializing devices that require the allocation of physical pages below 4 GB on some systems with 128 GB or more of physical memory. PR: 185727 Differential Revision: https://reviews.freebsd.org/D1274 Reviewed by: jhb, kib MFC after: 3 weeks Sponsored by: EMC / Isilon Storage Division
* Add workaround for vt efifb's early use of PHYS_TO_DMAPemaste2014-11-111-1/+7
| | | | | | | | | | | In vt_efifb_init the framebuffer's physaddr is passed to PHYS_TO_DMAP before the DMAP is setup. The result is not actually accessed until after the mapping is setup, though. Loosen the assertion in PHYS_TO_DMAP for now, to allow use when dmaplimit == 0. Reviewed by: kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D1142
* amd64: make uiomove_fromphys functional for pages not mapped by the DMAProyger2014-10-241-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Place the code introduced in r268660 into a separate function that can be called from uiomove_fromphys. Instead of pre-allocating two KVA pages use vmem_alloc to allocate them on demand when needed. This prevents blocking if a page fault is taken while physical addresses from outside the DMAP are used, since the lock is now removed. Also introduce a safety catch in PHYS_TO_DMAP and DMAP_TO_PHYS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D947 amd64/amd64/pmap.c: - Factor out the code to deal with non DMAP addresses from pmap_copy_pages and place it in pmap_map_io_transient. - Change the code to use vmem_alloc instead of a set of pre-allocated pages. - Use pmap_qenter and don't pin the thread if there can be page faults. amd64/amd64/uio_machdep.c: - Use pmap_map_io_transient in order to correctly deal with physical addresses not covered by the DMAP. amd64/include/pmap.h: - Add the prototypes for the new functions. amd64/include/vmparam.h: - Add safety catches to make sure PHYS_TO_DMAP and DMAP_TO_PHYS are only used with addresses covered by the DMAP.
* Increase max number of physical segments on amd64 to 63.kib2014-08-201-1/+1
| | | | | | | | | Eventually, the vmd_segs of the struct vm_domain should become bitset instead of long, to allow arbitrary compile-time selected maximum. Reviewed by: alc Sponsored by: The FreeBSD Foundation MFC after: 1 week
* As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In otheralc2013-11-081-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | words, every architecture is now auto-sizing the kmem arena. This revision changes kmeminit() so that the definition of VM_KMEM_SIZE_SCALE becomes mandatory and the definition of VM_KMEM_SIZE becomes optional. Replace or eliminate all existing definitions of VM_KMEM_SIZE. With auto-sizing enabled, VM_KMEM_SIZE effectively became an alternate spelling for VM_KMEM_SIZE_MIN on most architectures. Use VM_KMEM_SIZE_MIN for clarity. Change kmeminit() so that the effect of defining VM_KMEM_SIZE is similar to that of setting the tunable vm.kmem_size. Whereas the macros VM_KMEM_SIZE_{MAX,MIN,SCALE} have had the same effect as the tunables vm.kmem_size_{max,min,scale}, the effects of VM_KMEM_SIZE and vm.kmem_size have been distinct. In particular, whereas VM_KMEM_SIZE was overridden by VM_KMEM_SIZE_{MAX,MIN,SCALE} and vm.kmem_size_{max,min,scale}, vm.kmem_size was not. Remedy this inconsistency. Now, VM_KMEM_SIZE can be used to set the size of the kmem arena at compile-time without that value being overridden by auto-sizing. Update the nearby comments to reflect the kmem submap being replaced by the kmem arena. Stop duplicating the auto-sizing formula in every machine- dependent vmparam.h and place it in kmeminit() where auto-sizing takes place. Reviewed by: kib (an earlier version) Sponsored by: EMC / Isilon Storage Division
* Bump up the maximum addressable memory on amd64 systems from 1TB to 4TB.neel2013-08-171-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | Bump up the KVA size proportionally from 512GB to 2TB. The number of page table pages used by the direct map is now calculated at run time based on 'Maxmem'. This means the small memory systems will not see any additional tax in terms of page table pages for the direct map. However all amd64 systems, regardless of the memory size, will use 3 more pages to accomodate the bump in the KVA size. More details available here: http://lists.freebsd.org/pipermail/freebsd-hackers/2013-June/043015.html http://lists.freebsd.org/pipermail/freebsd-current/2013-July/043143.html Tested with the following configurations: - Sandybridge server with 64GB of memory. - bhyve VM with 64MB of memory. - bhyve VM with a 8GB of memory with the memory segment above 4GB cuddling right up against the 4TB maximum memory limit. Discussed on: hackers@, current@ Submitted by: Chris Torek (torek@torek.net)
* Rename VM_NDOMAIN into MAXMEMDOM and move it into machine/param.h inattilio2013-05-071-7/+0
| | | | | | | | | order to match the MAXCPU concept. The change should also be useful for consolidation and consistency. Sponsored by: EMC / Isilon storage division Obtained from: jeff Reviewed by: alc
* Increase DFLDSIZ from 128 MiB to 32 GiB. On amd64 there's plenty of virtualrmh2012-04-271-1/+1
| | | | | | memory available, so there is no need to be so conservative about it. Reviewed by: arch
* Move the ZERO_REGION_SIZE to a machine-dependent file, as on manymdf2011-05-131-0/+2
| | | | | | | | | | | | | | | | | | 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
* Move repeated MAXSLP definition from machine/vmparam.h to sys/vmmeter.h.kib2011-01-091-11/+0
| | | | | | | Update the outdated comments describing MAXSLP and the process selection algorithm for swap out. Comments wording and reviewed by: alc
* Create shared (readonly) page. Each ABI may specify the use of page bykib2011-01-081-1/+2
| | | | | | | | | | | | | 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
* Make the size of the direct map easily configurable. Changing NDMPML4Ealc2010-11-261-3/+4
| | | | | | | | now suffices. Increase the size of the direct map to 1TB. An earler version of this patch was tested by sbruno@.
* amd64: reduce VM_KMEM_SIZE_SCALE to 1 allowing kernel to use more memoryavg2010-09-171-1/+1
| | | | | | | | | | | | | | | | | | | 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
* Very rough first cut at NUMA support for the physical page allocator. Forjhb2010-07-271-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* On Alan's advice, rather than do a wholesale conversion on a singlekmacy2010-04-301-0/+4
| | | | | | | | | | | | 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
* correct range in commentkmacy2009-05-161-1/+1
| | | | pointed out by alc
* update vm map commentkmacy2009-05-161-1/+0
| | | | pointed out by Larry Rosenman
* Increase default kernel map to 512GBkmacy2009-05-161-2/+2
| | | | | I briefly discussed this with alc. It could lead to problems for greater than 64GB. However, that seems unlikely in practice.
* Eliminate pmap_growkernel()'s dependence on create_pagetables() preallocatingalc2008-07-081-2/+2
| | | | | | | | | | | 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().)
* Increase the kernel map's size to 7GB, making room for a kmem map of sizealc2008-07-051-2/+2
| | | | | greater than 4GB. (Auto-sizing will set the ceiling on the kmem map size to 4.2GB.)
* Increase the ceiling on the kmem map's size to 3.6GB. Also, define thealc2008-07-031-1/+2
| | | | | | 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.
* Document the layout of the address space, borrowing heavily fromalc2008-06-301-2/+12
| | | | http://lists.freebsd.org/pipermail/freebsd-amd64/2005-July/005578.html
* Strictly speaking, the definition of VM_MAX_KERNEL_ADDRESS is wrong. However,alc2008-06-291-1/+1
| | | | | | | 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.
* Ensure that KERNBASE is no less than the virtual address -2GB.alc2008-06-231-1/+1
|
* Add configuration knobs for the superpage reservation system. Initially,alc2007-12-271-0/+14
| | | | the reservation will only be enabled on amd64.
* Change the management of cached pages (PQ_CACHE) in two fundamentalalc2007-09-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ways: (1) Cached pages are no longer kept in the object's resident page splay tree and memq. Instead, they are kept in a separate per-object splay tree of cached pages. However, access to this new per-object splay tree is synchronized by the _free_ page queues lock, not to be confused with the heavily contended page queues lock. Consequently, a cached page can be reclaimed by vm_page_alloc(9) without acquiring the object's lock or the page queues lock. This solves a problem independently reported by tegge@ and Isilon. Specifically, they observed the page daemon consuming a great deal of CPU time because of pages bouncing back and forth between the cache queue (PQ_CACHE) and the inactive queue (PQ_INACTIVE). The source of this problem turned out to be a deadlock avoidance strategy employed when selecting a cached page to reclaim in vm_page_select_cache(). However, the root cause was really that reclaiming a cached page required the acquisition of an object lock while the page queues lock was already held. Thus, this change addresses the problem at its root, by eliminating the need to acquire the object's lock. Moreover, keeping cached pages in the object's primary splay tree and memq was, in effect, optimizing for the uncommon case. Cached pages are reclaimed far, far more often than they are reactivated. Instead, this change makes reclamation cheaper, especially in terms of synchronization overhead, and reactivation more expensive, because reactivated pages will have to be reentered into the object's primary splay tree and memq. (2) Cached pages are now stored alongside free pages in the physical memory allocator's buddy queues, increasing the likelihood that large allocations of contiguous physical memory (i.e., superpages) will succeed. Finally, as a result of this change long-standing restrictions on when and where a cached page can be reclaimed and returned by vm_page_alloc(9) are eliminated. Specifically, calls to vm_page_alloc(9) specifying VM_ALLOC_INTERRUPT can now reclaim and return a formerly cached page. Consequently, a call to malloc(9) specifying M_NOWAIT is less likely to fail. Discussed with: many over the course of the summer, including jeff@, Justin Husted @ Isilon, peter@, tegge@ Tested by: an earlier version by kris@ Approved by: re (kensmith)
* Add the machine-specific definitions for configuring the new physicalalc2007-06-031-0/+38
| | | | | | | | | memory allocator. Set the size of phys_avail[] and dump_avail[] using one of these definitions. Approved by: re
* Define every architecture as either VM_PHYSSEG_DENSE oralc2007-05-051-0/+5
| | | | | | | | | | | | | | | | | | | | VM_PHYSSEG_SPARSE depending on whether the physical address space is densely or sparsely populated with memory. The effect of this definition is to determine which of two implementations of vm_page_array and PHYS_TO_VM_PAGE() is used. The legacy implementation is obtained by defining VM_PHYSSEG_DENSE, and a new implementation that trades off time for space is obtained by defining VM_PHYSSEG_SPARSE. For now, all architectures except for ia64 and sparc64 define VM_PHYSSEG_DENSE. Defining VM_PHYSSEG_SPARSE on ia64 allows the entirety of my Itanium 2's memory to be used. Previously, only the first 1 GB could be used. Defining VM_PHYSSEG_SPARSE on sparc64 allows USIIIi-based systems to boot without crashing. This change is a combination of Nathan Whitehorn's patch and my own work in perforce. Discussed with: kmacy, marius, Nathan Whitehorn PR: 112194
* Add support for specifying a minimal size for vm.kmem_size in the loader viasepotvin2007-04-211-1/+2
| | | | | | | | vm.kmem_size_min. Useful when using ZFS to make sure that vm.kmem size will be at least 256mb (for example) without forcing a particular value via vm.kmem_size. Approved by: njl (mentor) Reviewed by: alc
* Raise MAXDSIZ from 8G to 32G. The old limit was just an arbitary choicepeter2004-10-271-1/+1
| | | | | | | | that was greater than 4G. I originally used the same values as i386 in order to save opening a new PML4 page slot, but in the day of gigabytes of memory, worrying about a 4K page seems futile. Moving from 8 to 32G moves the page to a different index, it doesn't increase the number of pages used.
* Increase VM_KMEM_SIZE_MAX from 200MB to 400MB.alc2003-12-071-1/+1
| | | | Discussed with: peter
* Update the graffiti.peter2003-11-081-0/+2
|
* Re-raise the default datasize and stacksize now that the 32 bit execpeter2003-09-251-2/+2
| | | | support can clip it to sensible values.
* Oops. back out last commit. The data and stack limits are used by thepeter2003-09-231-2/+2
| | | | | | | | 32 bit binary stuff. 32 bit binaries do not like it much when the kernel tries hard to put things above the 8GB mark. I have a work-in-progress to fix this properly, but I didn't want to burn anybody with this yet.
* Increase the default data size limit from 512MB to 8GB. Increase defaultpeter2003-09-221-2/+2
| | | | stack limit from 64MB to 512MB.
* Fix the VADDR() macros to use either KVADDR() or UVADDR(), dependingpeter2003-07-091-8/+8
| | | | | | | | | | on the implied sign extension. The single unified VADDR() macro was not able to avoid sign extending the VM_MAXUSER_ADDRESS/USRSTACK values. Be explicit about UVADDR() (positive address space) and KVADDR() (kernel negative address space) to make mistakes show up more spectacularly. Increase user VM space from 1/2TB (512GB) to 128TB.
* Typo fix. oops.peter2003-05-231-1/+1
| | | | | Submitted by: jmallett Approved by: re (blanket amd64/*)
* Major pmap rework to take advantage of the larger address space on amd64peter2003-05-231-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | systems. Of note: - Implement a direct mapped region using 2MB pages. This eliminates the need for temporary mappings when getting ptes. This supports up to 512GB of physical memory for now. This should be enough for a while. - Implement a 4-tier page table system. Most of the infrastructure is there for 128TB of userland virtual address space, but only 512GB is presently enabled due to a mystery bug somewhere. The design of this was heavily inspired by the alpha pmap.c. - The kernel is moved into the negative address space(!). - The kernel has 2GB of KVM available. - Provide a uma memory allocator to use the direct map region to take advantage of the 2MB TLBs. - Fixed some assumptions in the bus_space macros about the ability to fit virtual addresses in an 'int'. Notable missing things: - pmap_growkernel() should be able to grow to 512GB of KVM by expanding downwards below kernbase. The kernel must be at the top 2GB of the negative address space because of gcc code generation strategies. - need to fix the >512GB user vm code. Approved by: re (blanket)
* Commit MD parts of a loosely functional AMD64 port. This is based onpeter2003-05-011-16/+9
| | | | | | | | | | | | | | | | | | | | | | a heavily stripped down FreeBSD/i386 (brutally stripped down actually) to attempt to get a stable base to start from. There is a lot missing still. Worth noting: - The kernel runs at 1GB in order to cheat with the pmap code. pmap uses a variation of the PAE code in order to avoid having to worry about 4 levels of page tables yet. - It boots in 64 bit "long mode" with a tiny trampoline embedded in the i386 loader. This simplifies locore.s greatly. - There are still quite a few fragments of i386-specific code that have not been translated yet, and some that I cheated and wrote dumb C versions of (bcopy etc). - It has both int 0x80 for syscalls (but using registers for argument passing, as is native on the amd64 ABI), and the 'syscall' instruction for syscalls. int 0x80 preserves all registers, 'syscall' does not. - I have tried to minimize looking at the NetBSD code, except in a couple of places (eg: to find which register they use to replace the trashed %rcx register in the syscall instruction). As a result, there is not a lot of similarity. I did look at NetBSD a few times while debugging to get some ideas about what I might have done wrong in my first attempt.
* Better fix for previous previous which still allows the 4megs of kva atjake2003-04-071-1/+1
| | | | | | | | | | | the top of the address space to be reclaimed. The problem is that with the APTD gone the mapable kernel address space runs right to the end of the 32 bit address space. As a max this is 0x100000000, which can't be represented in 32 bits, so we have to use ptd entry n-1 and pte offset n-1, instead of ptd entry n and pte offset 0. There's still 1 page we can't use, but we gain just under 4 megs of kva (8 megs with PAE). Sponsored by: DARPA, Network Associates Laboratories
* - Removed UMAXPTDI and UMAXPTEOFF.jake2003-02-241-1/+1
| | | | | | | | | - Changed VM_MAXUSER_ADDRESS to be defined in terms of PTDPTDI. In order for assumptions about the recursive page table map to work it must be the base of the recursive map. Any pte offset that's not NPTEPG will break these assumptions. Sponsored by: DARPA, Network Associates Laboratories
* Make sysv-style shared memory tuneable params fully runtime adjustablepeter2000-03-301-7/+0
| | | | | | | | via sysctl. It's done pretty simply but it should be quite adequate. Also move SHMMAXPGS from $machine/include/vmparam.h as the comments that went with it were wrong... we don't allocate KVM space for the pages so that comment is bogus.. The only practical limit is how much physical ram you want to lock up as this stuff isn't paged out or swap backed.
* $Id$ -> $FreeBSD$peter1999-08-281-1/+1
|
* Increased max kmem to 200MB. This should fix some out-of-kmem panics ondg1999-07-241-2/+2
| | | | large systems.
* Increased MAXTSIZ to 128MB...there are binaries that get quite large.dg1998-06-121-3/+3
| | | | | Increased DFLDSIZ to 128MB, as it is a better default. Reviewed by: jkh
* Try to dynamically size the VM_KMEM_SIZE (but is still able to be overriddendyson1998-02-231-2/+18
| | | | | | | | | | | | in a way identically as before.) I had problems with the system properly handling the number of vnodes when there is alot of system memory, and the default VM_KMEM_SIZE. Two new options "VM_KMEM_SIZE_SCALE" and "VM_KMEM_SIZE_MAX" have been added to support better auto-sizing for systems with greater than 128MB. Add some accouting for vm_zone memory allocations, and provide properly for vm_zone allocations out of the kmem_map. Also move the vm_zone allocation stats to the VM OID tree from the KERN OID tree.
OpenPOWER on IntegriCloud