#
bca9d05f |
| 23-Jul-2017 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Merge ^/head r319973 through 321382.
|
Revision tags: release/11.1.0 |
|
#
a3604b95 |
| 27-Jun-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r320042 through r320397.
|
#
19bd0d9c |
| 24-Jun-2017 |
Konstantin Belousov <kib@FreeBSD.org> |
Implement address space guards.
Guard, requested by the MAP_GUARD mmap(2) flag, prevents the reuse of the allocated address space, but does not allow instantiation of the pages in the range. It is
Implement address space guards.
Guard, requested by the MAP_GUARD mmap(2) flag, prevents the reuse of the allocated address space, but does not allow instantiation of the pages in the range. It is useful for more explicit support for usual two-stage reserve then commit allocators, since it prevents accidental instantiation of the mapping, e.g. by mprotect(2).
Use guards to reimplement stack grow code. Explicitely track stack grow area with the guard, including the stack guard page. On stack grow, trivial shift of the guard map entry and stack map entry limits makes the stack expansion. Move the code to detect stack grow and call vm_map_growstack(), from vm_fault() into vm_map_lookup().
As result, it is impossible to get random mapping to occur in the stack grow area, or to overlap the stack guard page.
Enable stack guard page by default.
Reviewed by: alc, markj Man page update reviewed by: alc, bjk, emaste, markj, pho Tested by: pho, Qualys Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D11306 (man pages)
show more ...
|
#
78d7964b |
| 14-Mar-2017 |
Xin LI <delphij@FreeBSD.org> |
Implement INHERIT_ZERO for minherit(2).
INHERIT_ZERO is an OpenBSD feature.
When a page is marked as such, it would be zeroed upon fork().
This would be used in new arc4random(3) functions.
PR: 1
Implement INHERIT_ZERO for minherit(2).
INHERIT_ZERO is an OpenBSD feature.
When a page is marked as such, it would be zeroed upon fork().
This would be used in new arc4random(3) functions.
PR: 182610 Reviewed by: kib (earlier version) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D427
show more ...
|
#
348238db |
| 01-Mar-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r314420 through r314481.
|
#
fbbd9655 |
| 01-Mar-2017 |
Warner Losh <imp@FreeBSD.org> |
Renumber copyright clause 4
Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is
Renumber copyright clause 4
Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu> Pull Request: https://github.com/freebsd/freebsd/pull/96
show more ...
|
Revision tags: release/11.0.1, release/11.0.0 |
|
#
cc981af2 |
| 20-May-2016 |
John Baldwin <jhb@FreeBSD.org> |
Add new bus methods for mapping resources.
Add a pair of bus methods that can be used to "map" resources for direct CPU access using bus_space(9). bus_map_resource() creates a mapping and bus_unmap
Add new bus methods for mapping resources.
Add a pair of bus methods that can be used to "map" resources for direct CPU access using bus_space(9). bus_map_resource() creates a mapping and bus_unmap_resource() releases a previously created mapping. Mappings are described by 'struct resource_map' object. Pointers to these objects can be passed as the first argument to the bus_space wrapper API used for bus resources.
Drivers that wish to map all of a resource using default settings (for example, using uncacheable memory attributes) do not need to change. However, drivers that wish to use non-default settings can now do so without jumping through hoops.
First, an RF_UNMAPPED flag is added to request that a resource is not implicitly mapped with the default settings when it is activated. This permits other activation steps (such as enabling I/O or memory decoding in a device's PCI command register) to be taken without creating a mapping. Right now the AGP drivers don't set RF_ACTIVE to avoid using up a large amount of KVA to map the AGP aperture on 32-bit platforms. Once RF_UNMAPPED is supported on all platforms that support AGP this can be changed to using RF_UNMAPPED with RF_ACTIVE instead.
Second, bus_map_resource accepts an optional structure that defines additional settings for a given mapping.
For example, a driver can now request to map only a subset of a resource instead of the entire range. The AGP driver could also use this to only map the first page of the aperture (IIRC, it calls pmap_mapdev() directly to map the first page currently). I will also eventually change the PCI-PCI bridge driver to request mappings of the subset of the I/O window resource on its parent side to create mappings for child devices rather than passing child resources directly up to nexus to be mapped. This also permits bridges that do address translation to request suitable mappings from a resource on the "upper" side of the bus when mapping resources on the "lower" side of the bus.
Another attribute that can be specified is an alternate memory attribute for memory-mapped resources. This can be used to request a Write-Combining mapping of a PCI BAR in an MI fashion. (Currently the drivers that do this call pmap_change_attr() directly for x86 only.)
Note that this commit only adds the MI framework. Each platform needs to add support for handling RF_UNMAPPED and thew new bus_map/unmap_resource methods. Generally speaking, any drivers that are calling rman_set_bustag() and rman_set_bushandle() need to be updated.
Discussed on: arch Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D5237
show more ...
|
Revision tags: release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0 |
|
#
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 |
|
#
d1d01586 |
| 05-Sep-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head
|
#
40f65a4d |
| 07-Aug-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r254014
|
#
672ed870 |
| 02-Aug-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r253862
- change the SI_SUB_RUN_SCHEDULER sysinits in hv_utilc and hv_netvsc_drv_freebsd.c to SI_SUB_KTHREAD_IDLE, since the former is no longer in FreeBSD. The use of these SYSINITs can pro
IFC @ r253862
- change the SI_SUB_RUN_SCHEDULER sysinits in hv_utilc and hv_netvsc_drv_freebsd.c to SI_SUB_KTHREAD_IDLE, since the former is no longer in FreeBSD. The use of these SYSINITs can probably be removed.
show more ...
|
#
785797c3 |
| 24-Jul-2013 |
Andriy Gapon <avg@FreeBSD.org> |
rename scheduler->swapper and SI_SUB_RUN_SCHEDULER->SI_SUB_LAST
Also directly call swapper() at the end of mi_startup instead of relying on swapper being the last thing in sysinits order.
Rationale
rename scheduler->swapper and SI_SUB_RUN_SCHEDULER->SI_SUB_LAST
Also directly call swapper() at the end of mi_startup instead of relying on swapper being the last thing in sysinits order.
Rationale:
- "RUN_SCHEDULER" was misleading, scheduling already takes place at that stage - "scheduler" was misleading, the function swaps in the swapped out processes - another SYSINIT(SI_SUB_RUN_SCHEDULER, SI_ORDER_ANY) could never be invoked depending on its relative order with scheduler; this was not obvious and the bug actually used to exist
Reviewed by: kib (ealier version) MFC after: 14 days
show more ...
|
#
552311f4 |
| 17-Jul-2013 |
Xin LI <delphij@FreeBSD.org> |
IFC @253398
|
#
ceae90c2 |
| 05-Jul-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r252763
|
#
5f518366 |
| 28-Jun-2013 |
Jeff Roberson <jeff@FreeBSD.org> |
- Add a general purpose resource allocator, vmem, from NetBSD. It was originally inspired by the Solaris vmem detailed in the proceedings of usenix 2001. The NetBSD version was heavily refact
- Add a general purpose resource allocator, vmem, from NetBSD. It was originally inspired by the Solaris vmem detailed in the proceedings of usenix 2001. The NetBSD version was heavily refactored for bugs and simplicity. - Use this resource allocator to allocate the buffer and transient maps. Buffer cache defrags are reduced by 25% when used by filesystems with mixed block sizes. Ultimately this may permit dynamic buffer cache sizing on low KVA machines.
Discussed with: alc, kib, attilio Tested by: pho Sponsored by: EMC / Isilon Storage Division
show more ...
|
#
cfe30d02 |
| 19-Jun-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge fresh head.
|
Revision tags: release/8.4.0 |
|
#
69e6d7b7 |
| 12-Apr-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
sync from head
|
#
ee75e7de |
| 19-Mar-2013 |
Konstantin Belousov <kib@FreeBSD.org> |
Implement the concept of the unmapped VMIO buffers, i.e. buffers which do not map the b_pages pages into buffer_map KVA. The use of the unmapped buffers eliminate the need to perform TLB shootdown f
Implement the concept of the unmapped VMIO buffers, i.e. buffers which do not map the b_pages pages into buffer_map KVA. The use of the unmapped buffers eliminate the need to perform TLB shootdown for mapping on the buffer creation and reuse, greatly reducing the amount of IPIs for shootdown on big-SMP machines and eliminating up to 25-30% of the system time on i/o intensive workloads.
The unmapped buffer should be explicitely requested by the GB_UNMAPPED flag by the consumer. For unmapped buffer, no KVA reservation is performed at all. The consumer might request unmapped buffer which does have a KVA reserve, to manually map it without recursing into buffer cache and blocking, with the GB_KVAALLOC flag.
When the mapped buffer is requested and unmapped buffer already exists, the cache performs an upgrade, possibly reusing the KVA reservation.
Unmapped buffer is translated into unmapped bio in g_vfs_strategy(). Unmapped bio carry a pointer to the vm_page_t array, offset and length instead of the data pointer. The provider which processes the bio should explicitely specify a readiness to accept unmapped bio, otherwise g_down geom thread performs the transient upgrade of the bio request by mapping the pages into the new bio_transient_map KVA submap.
The bio_transient_map submap claims up to 10% of the buffer map, and the total buffer_map + bio_transient_map KVA usage stays the same. Still, it could be manually tuned by kern.bio_transient_maxcnt tunable, in the units of the transient mappings. Eventually, the bio_transient_map could be removed after all geom classes and drivers can accept unmapped i/o requests.
Unmapped support can be turned off by the vfs.unmapped_buf_allowed tunable, disabling which makes the buffer (or cluster) creation requests to ignore GB_UNMAPPED and GB_KVAALLOC flags. Unmapped buffers are only enabled by default on the architectures where pmap_copy_page() was implemented and tested.
In the rework, filesystem metadata is not the subject to maxbufspace limit anymore. Since the metadata buffers are always mapped, the buffers still have to fit into the buffer map, which provides a reasonable (but practically unreachable) upper bound on it. The non-metadata buffer allocations, both mapped and unmapped, is accounted against maxbufspace, as before. Effectively, this means that the maxbufspace is forced on mapped and unmapped buffers separately. The pre-patch bufspace limiting code did not worked, because buffer_map fragmentation does not allow the limit to be reached.
By Jeff Roberson request, the getnewbuf() function was split into smaller single-purpose functions.
Sponsored by: The FreeBSD Foundation Discussed with: jeff (previous version) Tested by: pho, scottl (previous version), jhb, bf MFC after: 2 weeks
show more ...
|
#
d241a0e6 |
| 26-Feb-2013 |
Xin LI <delphij@FreeBSD.org> |
IFC @247348.
|
#
d9a44755 |
| 08-Feb-2013 |
David E. O'Brien <obrien@FreeBSD.org> |
Sync with HEAD.
|
#
46b1c55d |
| 04-Jan-2013 |
Neel Natu <neel@FreeBSD.org> |
IFC @ r244983.
|
#
7e19eda4 |
| 18-Dec-2012 |
Andrey Zonov <zont@FreeBSD.org> |
- Fix locked memory accounting for maps with MAP_WIREFUTURE flag. - Add sysctl vm.old_mlock which may turn such accounting off.
Reviewed by: avg, trasz Approved by: kib (mentor) MFC after: 1 week
|
Revision tags: release/9.1.0 |
|
#
b652778e |
| 11-Jul-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r238370
|
#
31ccd489 |
| 28-May-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r236168.
|