#
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
|