History log of /freebsd/sys/amd64/include/vmparam.h (Results 51 – 75 of 210)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 5c9ef378 04-Nov-2014 Alexander V. Chernikov <melifaro@FreeBSD.org>

Sync to HEAD@r274095.


# 927dc0e0 24-Oct-2014 Roger Pau Monné <royger@FreeBSD.org>

amd64: make uiomove_fromphys functional for pages not mapped by the DMAP

Place the code introduced in r268660 into a separate function that can be
called from uiomove_fromphys. Instead of pre-alloca

amd64: make uiomove_fromphys functional for pages not mapped by the DMAP

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.

show more ...


# 4e27d36d 17-Sep-2014 Neel Natu <neel@FreeBSD.org>

IFC @r271694


# 832fd780 23-Aug-2014 Alexander V. Chernikov <melifaro@FreeBSD.org>

Sync to HEAD@r270409.


# 3165194c 20-Aug-2014 Konstantin Belousov <kib@FreeBSD.org>

Increase max number of physical segments on amd64 to 63.

Eventually, the vmd_segs of the struct vm_domain should become bitset
instead of long, to allow arbitrary compile-time selected maximum.

Rev

Increase max number of physical segments on amd64 to 63.

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

show more ...


Revision tags: release/9.3.0
# 3b8f0845 28-Apr-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge head


# 84e51a1b 23-Apr-2014 Alan Somers <asomers@FreeBSD.org>

IFC @264767


# 485ac45a 04-Feb-2014 Peter Grehan <grehan@FreeBSD.org>

MFC @ r259205 in preparation for some SVM updates. (for real this time)


Revision tags: release/10.0.0
# 50d3286d 11-Nov-2013 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r232040 through r258006.


# c70af487 08-Nov-2013 Alan Cox <alc@FreeBSD.org>

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

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

show more ...


# 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


# 0ef2ab3a 17-Aug-2013 Neel Natu <neel@FreeBSD.org>

Bump up the maximum addressable memory on amd64 systems from 1TB to 4TB.
Bump up the KVA size proportionally from 512GB to 2TB.

The number of page table pages used by the direct map is now calculate

Bump up the maximum addressable memory on amd64 systems from 1TB to 4TB.
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)

show more ...


# 40f65a4d 07-Aug-2013 Peter Grehan <grehan@FreeBSD.org>

IFC @ r254014


# 552311f4 17-Jul-2013 Xin LI <delphij@FreeBSD.org>

IFC @253398


# cfe30d02 19-Jun-2013 Gleb Smirnoff <glebius@FreeBSD.org>

Merge fresh head.


Revision tags: release/8.4.0
# 941646f5 08-May-2013 Attilio Rao <attilio@FreeBSD.org>

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 / Isilo

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

show more ...


Revision tags: release/9.1.0
# b652778e 11-Jul-2012 Peter Grehan <grehan@FreeBSD.org>

IFC @ r238370


# 6a068746 15-May-2012 Alexander Motin <mav@FreeBSD.org>

MFC


# 3d328873 30-Apr-2012 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r233826 through r234834.


# 74269bb4 28-Apr-2012 Robert Millan <rmh@FreeBSD.org>

Increase DFLDSIZ from 128 MiB to 32 GiB. On amd64 there's plenty of virtual
memory available, so there is no need to be so conservative about it.

Reviewed by: arch


Revision tags: release/8.3.0_cvs, release/8.3.0, release/9.0.0
# b2aa562e 13-May-2011 Attilio Rao <attilio@FreeBSD.org>

MFC


123456789