2001-06-10 02:39:37 +00:00
|
|
|
/*-
|
|
|
|
|
* Copyright (C) 1995, 1996 Wolfgang Solfrank.
|
|
|
|
|
* Copyright (C) 1995, 1996 TooLs GmbH.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
|
* This product includes software developed by TooLs GmbH.
|
|
|
|
|
* 4. The name of TooLs GmbH may not be used to endorse or promote products
|
|
|
|
|
* derived from this software without specific prior written permission.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY TOOLS GMBH ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
|
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
|
* IN NO EVENT SHALL TOOLS GMBH BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
|
|
|
|
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
|
|
|
|
|
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
|
|
|
|
|
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
|
|
|
|
|
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
|
|
|
|
|
* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
*
|
|
|
|
|
* $NetBSD: vmparam.h,v 1.11 2000/02/11 19:25:16 thorpej Exp $
|
|
|
|
|
* $FreeBSD$
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _MACHINE_VMPARAM_H_
|
|
|
|
|
#define _MACHINE_VMPARAM_H_
|
|
|
|
|
|
2011-01-14 11:36:44 +00:00
|
|
|
#define USRSTACK SHAREDPAGE
|
2001-06-10 02:39:37 +00:00
|
|
|
|
|
|
|
|
#ifndef MAXTSIZ
|
2015-01-10 06:54:10 +00:00
|
|
|
#define MAXTSIZ (1*1024*1024*1024) /* max text size */
|
2001-06-10 02:39:37 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef DFLDSIZ
|
2009-12-02 06:49:22 +00:00
|
|
|
#define DFLDSIZ (128*1024*1024) /* default data size */
|
2001-06-10 02:39:37 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef MAXDSIZ
|
2009-12-02 06:49:22 +00:00
|
|
|
#define MAXDSIZ (1*1024*1024*1024) /* max data size */
|
2001-06-10 02:39:37 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef DFLSSIZ
|
2009-12-02 06:49:22 +00:00
|
|
|
#define DFLSSIZ (8*1024*1024) /* default stack size */
|
2001-06-10 02:39:37 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef MAXSSIZ
|
2009-12-02 06:49:22 +00:00
|
|
|
#define MAXSSIZ (64*1024*1024) /* max stack size */
|
2001-06-10 02:39:37 +00:00
|
|
|
#endif
|
|
|
|
|
|
2011-12-11 17:23:03 +00:00
|
|
|
#ifdef AIM
|
|
|
|
|
#define VM_MAXUSER_ADDRESS32 ((vm_offset_t)0xfffff000)
|
|
|
|
|
#else
|
|
|
|
|
#define VM_MAXUSER_ADDRESS32 ((vm_offset_t)0x7ffff000)
|
|
|
|
|
#endif
|
|
|
|
|
|
2001-06-10 02:39:37 +00:00
|
|
|
/*
|
|
|
|
|
* Would like to have MAX addresses = 0, but this doesn't (currently) work
|
|
|
|
|
*/
|
2008-03-03 13:20:52 +00:00
|
|
|
#if !defined(LOCORE)
|
2010-07-13 05:32:19 +00:00
|
|
|
#ifdef __powerpc64__
|
|
|
|
|
#define VM_MIN_ADDRESS (0x0000000000000000UL)
|
2011-12-11 17:23:03 +00:00
|
|
|
#define VM_MAXUSER_ADDRESS (0xfffffffffffff000UL)
|
2010-07-13 05:32:19 +00:00
|
|
|
#define VM_MAX_ADDRESS (0xffffffffffffffffUL)
|
|
|
|
|
#else
|
2001-06-10 02:39:37 +00:00
|
|
|
#define VM_MIN_ADDRESS ((vm_offset_t)0)
|
2011-12-11 17:23:03 +00:00
|
|
|
#define VM_MAXUSER_ADDRESS VM_MAXUSER_ADDRESS32
|
|
|
|
|
#define VM_MAX_ADDRESS ((vm_offset_t)0xffffffff)
|
2010-07-13 05:32:19 +00:00
|
|
|
#endif
|
2011-12-11 17:23:03 +00:00
|
|
|
#define SHAREDPAGE (VM_MAXUSER_ADDRESS - PAGE_SIZE)
|
2010-07-13 05:32:19 +00:00
|
|
|
#else /* LOCORE */
|
2012-05-27 10:25:20 +00:00
|
|
|
#if !defined(__powerpc64__) && defined(BOOKE)
|
2008-03-03 13:20:52 +00:00
|
|
|
#define VM_MIN_ADDRESS 0
|
|
|
|
|
#define VM_MAXUSER_ADDRESS 0x7ffff000
|
2010-07-13 05:32:19 +00:00
|
|
|
#endif
|
2008-03-03 13:20:52 +00:00
|
|
|
#endif /* LOCORE */
|
|
|
|
|
|
2011-12-11 17:23:03 +00:00
|
|
|
#define FREEBSD32_SHAREDPAGE (VM_MAXUSER_ADDRESS32 - PAGE_SIZE)
|
2011-01-14 11:36:44 +00:00
|
|
|
#define FREEBSD32_USRSTACK FREEBSD32_SHAREDPAGE
|
2008-03-03 13:20:52 +00:00
|
|
|
|
2010-07-13 05:32:19 +00:00
|
|
|
#ifdef AIM
|
|
|
|
|
#define KERNBASE 0x00100000UL /* start of kernel virtual */
|
2008-03-03 13:20:52 +00:00
|
|
|
|
2010-07-13 05:32:19 +00:00
|
|
|
#ifdef __powerpc64__
|
|
|
|
|
#define VM_MIN_KERNEL_ADDRESS 0xc000000000000000UL
|
|
|
|
|
#define VM_MAX_KERNEL_ADDRESS 0xc0000001c7ffffffUL
|
|
|
|
|
#define VM_MAX_SAFE_KERNEL_ADDRESS VM_MAX_KERNEL_ADDRESS
|
|
|
|
|
#else
|
|
|
|
|
#define VM_MIN_KERNEL_ADDRESS ((vm_offset_t)KERNEL_SR << ADDR_SR_SHFT)
|
2010-02-20 16:23:29 +00:00
|
|
|
#define VM_MAX_SAFE_KERNEL_ADDRESS (VM_MIN_KERNEL_ADDRESS + 2*SEGMENT_LENGTH -1)
|
|
|
|
|
#define VM_MAX_KERNEL_ADDRESS (VM_MIN_KERNEL_ADDRESS + 3*SEGMENT_LENGTH - 1)
|
2010-07-13 05:32:19 +00:00
|
|
|
#endif
|
2001-06-10 02:39:37 +00:00
|
|
|
|
2008-03-03 13:20:52 +00:00
|
|
|
/*
|
|
|
|
|
* Use the direct-mapped BAT registers for UMA small allocs. This
|
|
|
|
|
* takes pressure off the small amount of available KVA.
|
|
|
|
|
*/
|
|
|
|
|
#define UMA_MD_SMALL_ALLOC
|
|
|
|
|
|
2010-07-13 05:32:19 +00:00
|
|
|
#else /* Book-E */
|
2008-03-03 13:20:52 +00:00
|
|
|
|
|
|
|
|
#define KERNBASE 0xc0000000 /* start of kernel virtual */
|
|
|
|
|
|
|
|
|
|
#define VM_MIN_KERNEL_ADDRESS KERNBASE
|
2009-04-21 17:08:02 +00:00
|
|
|
#define VM_MAX_KERNEL_ADDRESS 0xf8000000
|
2013-10-27 14:03:51 +00:00
|
|
|
#define VM_MAX_SAFE_KERNEL_ADDRESS VM_MAX_KERNEL_ADDRESS
|
2008-03-03 13:20:52 +00:00
|
|
|
|
|
|
|
|
#endif /* AIM/E500 */
|
2004-02-11 07:27:34 +00:00
|
|
|
|
2008-03-03 13:20:52 +00:00
|
|
|
#if !defined(LOCORE)
|
2001-06-10 02:39:37 +00:00
|
|
|
struct pmap_physseg {
|
|
|
|
|
struct pv_entry *pvent;
|
|
|
|
|
char *attrs;
|
|
|
|
|
};
|
2008-03-03 13:20:52 +00:00
|
|
|
#endif
|
2001-06-10 02:39:37 +00:00
|
|
|
|
|
|
|
|
#define VM_PHYSSEG_MAX 16 /* 1? */
|
|
|
|
|
|
2007-05-05 19:50:28 +00:00
|
|
|
/*
|
2010-12-20 14:25:01 +00:00
|
|
|
* The physical address space is densely populated on 32-bit systems,
|
|
|
|
|
* but may not be on 64-bit ones.
|
2007-05-05 19:50:28 +00:00
|
|
|
*/
|
2010-12-20 14:25:01 +00:00
|
|
|
#ifdef __powerpc64__
|
|
|
|
|
#define VM_PHYSSEG_SPARSE
|
|
|
|
|
#else
|
2007-05-05 19:50:28 +00:00
|
|
|
#define VM_PHYSSEG_DENSE
|
2010-12-20 14:25:01 +00:00
|
|
|
#endif
|
2007-05-05 19:50:28 +00:00
|
|
|
|
Enable the new physical memory allocator.
This allocator uses a binary buddy system with a twist. First and
foremost, this allocator is required to support the implementation of
superpages. As a side effect, it enables a more robust implementation
of contigmalloc(9). Moreover, this reimplementation of
contigmalloc(9) eliminates the acquisition of Giant by
contigmalloc(..., M_NOWAIT, ...).
The twist is that this allocator tries to reduce the number of TLB
misses incurred by accesses through a direct map to small, UMA-managed
objects and page table pages. Roughly speaking, the physical pages
that are allocated for such purposes are clustered together in the
physical address space. The performance benefits vary. In the most
extreme case, a uniprocessor kernel running on an Opteron, I measured
an 18% reduction in system time during a buildworld.
This allocator does not implement page coloring. The reason is that
superpages have much the same effect. The contiguous physical memory
allocation necessary for a superpage is inherently colored.
Finally, the one caveat is that this allocator does not effectively
support prezeroed pages. I hope this is temporary. On i386, this is
a slight pessimization. However, on amd64, the beneficial effects of
the direct-map optimization outweigh the ill effects. I speculate
that this is true in general of machines with a direct map.
Approved by: re
2007-06-16 04:57:06 +00:00
|
|
|
/*
|
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)
2007-09-25 06:25:06 +00:00
|
|
|
* Create three free page pools: VM_FREEPOOL_DEFAULT is the default pool
|
Enable the new physical memory allocator.
This allocator uses a binary buddy system with a twist. First and
foremost, this allocator is required to support the implementation of
superpages. As a side effect, it enables a more robust implementation
of contigmalloc(9). Moreover, this reimplementation of
contigmalloc(9) eliminates the acquisition of Giant by
contigmalloc(..., M_NOWAIT, ...).
The twist is that this allocator tries to reduce the number of TLB
misses incurred by accesses through a direct map to small, UMA-managed
objects and page table pages. Roughly speaking, the physical pages
that are allocated for such purposes are clustered together in the
physical address space. The performance benefits vary. In the most
extreme case, a uniprocessor kernel running on an Opteron, I measured
an 18% reduction in system time during a buildworld.
This allocator does not implement page coloring. The reason is that
superpages have much the same effect. The contiguous physical memory
allocation necessary for a superpage is inherently colored.
Finally, the one caveat is that this allocator does not effectively
support prezeroed pages. I hope this is temporary. On i386, this is
a slight pessimization. However, on amd64, the beneficial effects of
the direct-map optimization outweigh the ill effects. I speculate
that this is true in general of machines with a direct map.
Approved by: re
2007-06-16 04:57:06 +00:00
|
|
|
* from which physical pages are allocated and VM_FREEPOOL_DIRECT is
|
|
|
|
|
* the pool from which physical pages for small UMA objects are
|
|
|
|
|
* allocated.
|
|
|
|
|
*/
|
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)
2007-09-25 06:25:06 +00:00
|
|
|
#define VM_NFREEPOOL 3
|
|
|
|
|
#define VM_FREEPOOL_CACHE 2
|
Enable the new physical memory allocator.
This allocator uses a binary buddy system with a twist. First and
foremost, this allocator is required to support the implementation of
superpages. As a side effect, it enables a more robust implementation
of contigmalloc(9). Moreover, this reimplementation of
contigmalloc(9) eliminates the acquisition of Giant by
contigmalloc(..., M_NOWAIT, ...).
The twist is that this allocator tries to reduce the number of TLB
misses incurred by accesses through a direct map to small, UMA-managed
objects and page table pages. Roughly speaking, the physical pages
that are allocated for such purposes are clustered together in the
physical address space. The performance benefits vary. In the most
extreme case, a uniprocessor kernel running on an Opteron, I measured
an 18% reduction in system time during a buildworld.
This allocator does not implement page coloring. The reason is that
superpages have much the same effect. The contiguous physical memory
allocation necessary for a superpage is inherently colored.
Finally, the one caveat is that this allocator does not effectively
support prezeroed pages. I hope this is temporary. On i386, this is
a slight pessimization. However, on amd64, the beneficial effects of
the direct-map optimization outweigh the ill effects. I speculate
that this is true in general of machines with a direct map.
Approved by: re
2007-06-16 04:57:06 +00:00
|
|
|
#define VM_FREEPOOL_DEFAULT 0
|
|
|
|
|
#define VM_FREEPOOL_DIRECT 1
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Create one free page list.
|
|
|
|
|
*/
|
2001-06-10 02:39:37 +00:00
|
|
|
#define VM_NFREELIST 1
|
|
|
|
|
#define VM_FREELIST_DEFAULT 0
|
|
|
|
|
|
Enable the new physical memory allocator.
This allocator uses a binary buddy system with a twist. First and
foremost, this allocator is required to support the implementation of
superpages. As a side effect, it enables a more robust implementation
of contigmalloc(9). Moreover, this reimplementation of
contigmalloc(9) eliminates the acquisition of Giant by
contigmalloc(..., M_NOWAIT, ...).
The twist is that this allocator tries to reduce the number of TLB
misses incurred by accesses through a direct map to small, UMA-managed
objects and page table pages. Roughly speaking, the physical pages
that are allocated for such purposes are clustered together in the
physical address space. The performance benefits vary. In the most
extreme case, a uniprocessor kernel running on an Opteron, I measured
an 18% reduction in system time during a buildworld.
This allocator does not implement page coloring. The reason is that
superpages have much the same effect. The contiguous physical memory
allocation necessary for a superpage is inherently colored.
Finally, the one caveat is that this allocator does not effectively
support prezeroed pages. I hope this is temporary. On i386, this is
a slight pessimization. However, on amd64, the beneficial effects of
the direct-map optimization outweigh the ill effects. I speculate
that this is true in general of machines with a direct map.
Approved by: re
2007-06-16 04:57:06 +00:00
|
|
|
/*
|
|
|
|
|
* The largest allocation size is 4MB.
|
|
|
|
|
*/
|
|
|
|
|
#define VM_NFREEORDER 11
|
|
|
|
|
|
2007-12-27 16:45:39 +00:00
|
|
|
/*
|
|
|
|
|
* Disable superpage reservations.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef VM_NRESERVLEVEL
|
|
|
|
|
#define VM_NRESERVLEVEL 0
|
|
|
|
|
#endif
|
|
|
|
|
|
2001-06-10 02:39:37 +00:00
|
|
|
#ifndef VM_INITIAL_PAGEIN
|
|
|
|
|
#define VM_INITIAL_PAGEIN 16
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef SGROWSIZ
|
|
|
|
|
#define SGROWSIZ (128UL*1024) /* amount to grow stack */
|
|
|
|
|
#endif
|
|
|
|
|
|
As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In other
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
2013-11-08 16:25:00 +00:00
|
|
|
/*
|
|
|
|
|
* How many physical pages per kmem arena virtual page.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef VM_KMEM_SIZE_SCALE
|
|
|
|
|
#define VM_KMEM_SIZE_SCALE (3)
|
2001-06-10 02:39:37 +00:00
|
|
|
#endif
|
|
|
|
|
|
2013-10-27 14:03:51 +00:00
|
|
|
/*
|
As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In other
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
2013-11-08 16:25:00 +00:00
|
|
|
* Optional floor (in bytes) on the size of the kmem arena.
|
2013-10-27 14:03:51 +00:00
|
|
|
*/
|
As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In other
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
2013-11-08 16:25:00 +00:00
|
|
|
#ifndef VM_KMEM_SIZE_MIN
|
|
|
|
|
#define VM_KMEM_SIZE_MIN (12 * 1024 * 1024)
|
2010-07-13 05:32:19 +00:00
|
|
|
#endif
|
|
|
|
|
|
2013-10-27 14:03:51 +00:00
|
|
|
/*
|
As of r257209, all architectures have defined VM_KMEM_SIZE_SCALE. In other
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
2013-11-08 16:25:00 +00:00
|
|
|
* Optional ceiling (in bytes) on the size of the kmem arena: 40% of the
|
|
|
|
|
* usable KVA space.
|
2013-10-27 14:03:51 +00:00
|
|
|
*/
|
2010-07-13 05:32:19 +00:00
|
|
|
#ifndef VM_KMEM_SIZE_MAX
|
2013-10-27 14:03:51 +00:00
|
|
|
#define VM_KMEM_SIZE_MAX ((VM_MAX_SAFE_KERNEL_ADDRESS - \
|
|
|
|
|
VM_MIN_KERNEL_ADDRESS + 1) * 2 / 5)
|
2010-07-13 05:32:19 +00:00
|
|
|
#endif
|
|
|
|
|
|
2011-05-13 19:35:01 +00:00
|
|
|
#define ZERO_REGION_SIZE (64 * 1024) /* 64KB */
|
|
|
|
|
|
2014-08-05 09:44:10 +00:00
|
|
|
/*
|
|
|
|
|
* On 32-bit OEA, the only purpose for which sf_buf is used is to implement
|
|
|
|
|
* an opaque pointer required by the machine-independent parts of the kernel.
|
|
|
|
|
* That pointer references the vm_page that is "mapped" by the sf_buf. The
|
|
|
|
|
* actual mapping is provided by the direct virtual-to-physical mapping.
|
|
|
|
|
*
|
|
|
|
|
* On OEA64 and Book-E, we need to do something a little more complicated. Use
|
|
|
|
|
* the runtime-detected hw_direct_map to pick between the two cases. Our
|
|
|
|
|
* friends in vm_machdep.c will do the same to ensure nothing gets confused.
|
|
|
|
|
*/
|
|
|
|
|
#define SFBUF
|
|
|
|
|
#define SFBUF_NOMD
|
|
|
|
|
#define SFBUF_OPTIONAL_DIRECT_MAP hw_direct_map
|
2014-08-20 08:02:38 +00:00
|
|
|
#define SFBUF_PHYS_DMAP(x) (x)
|
2014-08-05 09:44:10 +00:00
|
|
|
|
2001-06-10 02:39:37 +00:00
|
|
|
#endif /* _MACHINE_VMPARAM_H_ */
|
