#
259065 |
|
07-Dec-2013 |
gjb |
- Copy stable/10 (r259064) to releng/10.0 as part of the 10.0-RELEASE cycle. - Update __FreeBSD_version [1] - Set branch name to -RC1
[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so start releng/10.0 at '100' so the branch is started with a value ending in zero.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
250338 |
|
07-May-2013 |
attilio |
Rename VM_NDOMAIN into MAXMEMDOM and move it into machine/param.h in 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
|
#
246554 |
|
08-Feb-2013 |
kib |
The 'end' word was missed in the comment.
MFC after: 3 days
|
#
240190 |
|
07-Sep-2012 |
gavin |
Prevent indent(1) from reformatting this comment, as it contains a formatting-sensitive table.
|
#
230630 |
|
27-Jan-2012 |
marius |
For machines where the kernel address space is unrestricted increase VM_KMEM_SIZE_SCALE to 2, awaiting more insight from alc@. As it turns out, the VM apparently has problems with machines that have large holes in the physical address space, causing the kmem_suballoc() call in kmeminit() to fail with a VM_KMEM_SIZE_SCALE of 1. Using a value of 2 allows these, namely Blade 1500 with 2GB of RAM, to boot.
PR: 164227
|
#
223379 |
|
21-Jun-2011 |
marius |
Fix whitespace
|
#
223378 |
|
21-Jun-2011 |
marius |
On machines where we don't need to lock the kernel TSB into the dTLB and thus may basically use the entire 64-bit kernel address space reduce VM_KMEM_SIZE_SCALE to 1 allowing kernel to use more memory.
|
#
221855 |
|
13-May-2011 |
mdf |
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
|
#
219608 |
|
13-Mar-2011 |
marius |
Remove the advertising clause from the UCB license according to the July 22, 1999 addendum.
|
#
217192 |
|
09-Jan-2011 |
kib |
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
|
#
216625 |
|
21-Dec-2010 |
marius |
Revert r216080 so kmem_map is capped at 3/5 of the currently rather modest kernel address space in order to leave space for the buffer cache, pipes, thread stacks, etc on machines with more physical memory until we take advantage of ASI_ATOMIC_QUAD_LDD_PHYS on CPUs providing it so we don't need to lock the kernel TSB pages into the dTLB, basically making the entire 64-bit kernel address space available on relevant machines.
Submitted by: alc
|
#
216080 |
|
30-Nov-2010 |
fjoe |
Change VM_KMEM_SIZE_MAX to be just (VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS)
Suggested by: marius
|
#
216016 |
|
28-Nov-2010 |
fjoe |
Define VM_KMEM_SIZE_MAX on sparc64. Otherwise kernel built with DEBUG_MEMGUARD panics early in kmeminit() with the message "kmem_suballoc: bad status return of 1" because of zero "size" argument passed to kmem_suballoc() due to "vm_kmem_size_max" being zero.
The problem also exists on ia64.
|
#
215093 |
|
10-Nov-2010 |
alc |
Enable reservation-based physical memory allocation. Even without the creation of large page mappings in the pmap, it can provide modest performance benefits. In particular, for a "buildworld" on a 2x 1GHz Ultrasparc IIIi it reduced the wall clock time by 2.2% and the system time by 12.6%.
Tested by: marius@
|
#
210550 |
|
27-Jul-2010 |
jhb |
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
|
#
188455 |
|
10-Feb-2009 |
marius |
- Use the generally more appropriate PROM base rather than the kernel one as the non-faulting flush address in the loader so we can can change KERNBASE and VM_MIN_KERNEL_ADDRESS if we ever want to without needing to worry about using a compatible loader. - Correctly check for LOADER_DEBUG. - Add a missing const for page_sizes[].
|
#
181642 |
|
12-Aug-2008 |
marius |
Assume OpenSolaris knows better and use their value for VM_MAX_PROM_ADDRESS.
|
#
174938 |
|
27-Dec-2007 |
alc |
Add configuration knobs for the superpage reservation system. Initially, the reservation will only be enabled on amd64.
|
#
172317 |
|
25-Sep-2007 |
alc |
Change the management of cached pages (PQ_CACHE) in two fundamental 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)
|
#
170262 |
|
04-Jun-2007 |
alc |
Add the machine-specific definitions for configuring the new physical memory allocator.
Approved by: re
|
#
169291 |
|
05-May-2007 |
alc |
Define every architecture as either VM_PHYSSEG_DENSE or 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
|
#
168920 |
|
20-Apr-2007 |
sepotvin |
Add support for specifying a minimal size for vm.kmem_size in the loader via 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
|
#
108332 |
|
27-Dec-2002 |
jake |
Define UMA_MD_SMALL_ALLOC so that uma_small_alloc and uma_small_free will be used for zones that allocate objects of less 1 page. The biggest advantage of this is that all of a sudden the majority of kernel malloc-ed data doesn't need kva allocated for it. Besides microbenchmarks I haven't seen a measurable performance improvement from doing this.
|
#
108245 |
|
23-Dec-2002 |
jake |
- Change the way the direct mapped region is implemented to be generally useful for accessing more than 1 page of contiguous physical memory, and to use 4mb tlb entries instead of 8k. This requires that the system only use the direct mapped addresses when they have the same virtual colour as all other mappings of the same page, instead of being able to choose the colour and cachability of the mapping. - Adapt the physical page copying and zeroing functions to account for not being able to choose the colour or cachability of the direct mapped address. This adds a lot more cases to handle. Basically when a page has a different colour than its direct mapped address we have a choice between bypassing the data cache and using physical addresses directly, which requires a cache flush, or mapping it at the right colour, which requires a tlb flush. For now we choose to map the page and do the tlb flush.
This will allows the direct mapped addresses to be used for more things that don't require normal pmap handling, including mapping the vm_page structures, the message buffer, temporary mappings for crash dumps, and will provide greater benefit for implementing uma_small_alloc, due to the much greater tlb coverage.
|
#
101653 |
|
10-Aug-2002 |
jake |
Auto size available kernel virtual address space based on phsyical memory size. This avoids blowing out kva in kmeminit() on large memory machines (4 gigs or more).
Reviewed by: tmm
|
#
99897 |
|
13-Jul-2002 |
jake |
Use a fixed address for KERNBASE, so it doesn't change if the size of KVA is increased. Its confusing for all the kernel addresses to change, and doesn't serve much purpose as far as conserving address space.
|
#
98350 |
|
17-Jun-2002 |
jake |
Add constants for the min and max prom addresses. Use these instead of magic numbers. Use stxa_sync instead of stxa; membar #Sync; to ensure that no instruction is placed between the two. This can cause random corruption even though interrupts are already disabled.
|
#
91974 |
|
09-Mar-2002 |
jake |
Increase VM_KMEM_SIZE to 16 megs from 12. Define VM_KMEM_SIZE_SCALE so that the number of physical pages per KVA page allocated scales properly with memory size. This fixes problems with kmem_map being too small.
Noticed by: mike, wollman Submitted by: tmm
|
#
88653 |
|
29-Dec-2001 |
jake |
Add comments as to why VM_MAXUSER_ADDRESS is magic (abitrary). Define the KVA_RANGE in terms of ttes, not sttes. Remove UPT_MIN_ADDRESS. We no longer use a hard coded address for the user tsb.
|
#
85241 |
|
20-Oct-2001 |
jake |
Parameterize the size of the kernel virtual address space on KVA_PAGES. Don't use a hard coded address constant for the virtual address of the kernel tsb. Allocate kernel virtual address space for the kernel tsb at runtime. Remove unused parameter to pmap_bootstrap. Adapt pmap.c to use KVA_PAGES. Map the message buffer too. Add some traces. Implement pmap_protect.
|
#
84183 |
|
30-Sep-2001 |
jake |
Move the kernel to end of the first 4 gigabytes of address space, so that one 4 meg page can map both the kernel and the openfirmware mappings. Add the openfirmware mappings to the kernel tsb so we can call the firmware on the kernel trap table and access kernel memory normally. Implement pmap_swapout_proc, pmap_swapin_proc, pmap_swapout_thread, pmap_swapin_thread, pmap_activate, pmap_page_exists, and pmap_phys_address.
|
#
82899 |
|
03-Sep-2001 |
jake |
Use the correct copyrights. Note where most of this came from.
Requested by: obrien
|
#
81334 |
|
09-Aug-2001 |
obrien |
The author isn't a [UC] Regents. Correct the copyright language.
|
#
81179 |
|
06-Aug-2001 |
jake |
The kernel runs at a much lower address now.
|
#
80709 |
|
31-Jul-2001 |
jake |
Flesh out the sparc64 port considerably. This contains: - mostly complete kernel pmap support, and tested but currently turned off userland pmap support - low level assembly language trap, context switching and support code - fully implemented atomic.h and supporting cpufunc.h - some support for kernel debugging with ddb - various header tweaks and filling out of machine dependent structures
|
#
80708 |
|
31-Jul-2001 |
jake |
Add skeleton machine dependent headers and c files for a port of freebsd to a new architecture. This is the base of the sparc64 port, but contains limited machine dependent code, and can be used a base for ports. Included are: - standard machine dependent headers, tweaked for a 64 bit, big endian architecture, including empty versions of all the machine dependent structures - a machine independent atomic.h, which can be used until a port has support for interrupts and the operations really need to be atomic - stub versions of all the machine dependent functions, which panic when called and print out the name of the function that needs to be implemented. functions which are normally in assembly files are not included, but this should reduce the number of different undefined references on the first few compiles from hundreds to 5 or 6 Given minimal startup code and console support it should be trivial to make this compile and run the first few sysinits on almost any architecture.
Requested by: alfred, imp, jhb
|