History log of /freebsd/sys/vm/vm_extern.h (Results 51 – 75 of 301)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# dad2fb7e 15-Jun-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from head


# 3adc74c7 09-Jun-2015 Dimitry Andric <dim@FreeBSD.org>

Merged ^/head r283871 through r284187.


# 7077c426 04-Jun-2015 John Baldwin <jhb@FreeBSD.org>

Add a new file operations hook for mmap operations. File type-specific
logic is now placed in the mmap hook implementation rather than requiring
it to be placed in sys/vm/vm_mmap.c. This hook allow

Add a new file operations hook for mmap operations. File type-specific
logic is now placed in the mmap hook implementation rather than requiring
it to be placed in sys/vm/vm_mmap.c. This hook allows new file types to
support mmap() as well as potentially allowing mmap() for existing file
types that do not currently support any mapping.

The vm_mmap() function is now split up into two functions. A new
vm_mmap_object() function handles the "back half" of vm_mmap() and accepts
a referenced VM object to map rather than a (handle, handle_type) tuple.
vm_mmap() is now reduced to converting a (handle, handle_type) tuple to a
a VM object and then calling vm_mmap_object() to handle the actual mapping.
The vm_mmap() function remains for use by other parts of the kernel
(e.g. device drivers and exec) but now only supports mapping vnodes,
character devices, and anonymous memory.

The mmap() system call invokes vm_mmap_object() directly with a NULL object
for anonymous mappings. For mappings using a file descriptor, the
descriptors fo_mmap() hook is invoked instead. The fo_mmap() hook is
responsible for performing type-specific checks and adjustments to
arguments as well as possibly modifying mapping parameters such as flags
or the object offset. The fo_mmap() hook routines then call
vm_mmap_object() to handle the actual mapping.

The fo_mmap() hook is optional. If it is not set, then fo_mmap() will
fail with ENODEV. A fo_mmap() hook is implemented for regular files,
character devices, and shared memory objects (created via shm_open()).

While here, consistently use the VM_PROT_* constants for the vm_prot_t
type for the 'prot' variable passed to vm_mmap() and vm_mmap_object()
as well as the vm_mmap_vnode() and vm_mmap_cdev() helper routines.
Previously some places were using the mmap()-specific PROT_* constants
instead. While this happens to work because PROT_xx == VM_PROT_xx,
using VM_PROT_* is more correct.

Differential Revision: https://reviews.freebsd.org/D2658
Reviewed by: alc (glanced over), kib
MFC after: 1 month
Sponsored by: Chelsio

show more ...


# 9268022b 19-Nov-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge from head@274682


Revision tags: release/10.1.0
# 246e7a2b 02-Sep-2014 Neel Natu <neel@FreeBSD.org>

IFC @r269962

Submitted by: Anish Gupta (akgupt3@gmail.com)


# ee7b0571 19-Aug-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge head from 7/28


# 1b833d53 13-Aug-2014 Alexander V. Chernikov <melifaro@FreeBSD.org>

Sync to HEAD@r269943.


# 66cd575b 02-Aug-2014 Alan Cox <alc@FreeBSD.org>

Handle wiring failures in vm_map_wire() with the new functions
pmap_unwire() and vm_object_unwire().

Retire vm_fault_{un,}wire(), since they are no longer used.

(See r268327 and r269134 for the mot

Handle wiring failures in vm_map_wire() with the new functions
pmap_unwire() and vm_object_unwire().

Retire vm_fault_{un,}wire(), since they are no longer used.

(See r268327 and r269134 for the motivation behind this change.)

Reviewed by: kib
Sponsored by: EMC / Isilon Storage Division

show more ...


# 03462509 26-Jul-2014 Alan Cox <alc@FreeBSD.org>

When unwiring a region of an address space, do not assume that the
underlying physical pages are mapped by the pmap. If, for example, the
application has performed an mprotect(..., PROT_NONE) on any

When unwiring a region of an address space, do not assume that the
underlying physical pages are mapped by the pmap. If, for example, the
application has performed an mprotect(..., PROT_NONE) on any part of the
wired region, then those pages will no longer be mapped by the pmap.
So, using the pmap to lookup the wired pages in order to unwire them
doesn't always work, and when it doesn't work wired pages are leaked.

To avoid the leak, introduce and use a new function vm_object_unwire()
that locates the wired pages by traversing the object and its backing
objects.

At the same time, switch from using pmap_change_wiring() to the recently
introduced function pmap_unwire() for unwiring the region's mappings.
pmap_unwire() is faster, because it operates a range of virtual addresses
rather than a single virtual page at a time. Moreover, by operating on
a range, it is superpage friendly. It doesn't waste time performing
unnecessary demotions.

Reported by: markj
Reviewed by: kib
Tested by: pho, jmg (arm)
Sponsored by: EMC / Isilon Storage Division

show more ...


Revision tags: release/9.3.0, release/10.0.0
# 064bee34 30-Oct-2013 Peter Grehan <grehan@FreeBSD.org>

MFC @ r256071

This is just prior to the bhyve_npt_pmap import so will allow
just the change to be merged for easier debug.


# 0bfd163f 18-Oct-2013 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r233826 through r256722.


# 3caf0790 13-Oct-2013 Simon J. Gerraty <sjg@FreeBSD.org>

Merge head@256284


# 1ccca3b5 10-Oct-2013 Alan Somers <asomers@FreeBSD.org>

IFC @256277

Approved by: ken (mentor)


# 27650413 02-Oct-2013 Mark Murray <markm@FreeBSD.org>

MFC - tracking update.


Revision tags: release/9.2.0
# 74d1d2b7 20-Sep-2013 Neel Natu <neel@FreeBSD.org>

Merge the following changes from projects/bhyve_npt_pmap:
- add fields to 'struct pmap' that are required to manage nested page tables.
- add a parameter to 'vmspace_alloc()' that can be used to over

Merge the following changes from projects/bhyve_npt_pmap:
- add fields to 'struct pmap' that are required to manage nested page tables.
- add a parameter to 'vmspace_alloc()' that can be used to override the
default pmap initialization routine 'pmap_pinit()'.

These changes are pushed ahead of the remaining changes in 'bhyve_npt_pmap'
in anticipation of the upcoming KBI freeze for 10.0.

Reviewed by: kib@, alc@
Approved by: re (glebius)

show more ...


# 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


# 5df87b21 07-Aug-2013 Jeff Roberson <jeff@FreeBSD.org>

Replace kernel virtual address space allocation with vmem. This provides
transparent layering and better fragmentation.

- Normalize functions that allocate memory to use kmem_*
- Those that alloc

Replace kernel virtual address space allocation with vmem. This provides
transparent layering and better fragmentation.

- Normalize functions that allocate memory to use kmem_*
- Those that allocate address space are named kva_*
- Those that operate on maps are named kmap_*
- Implement recursive allocation handling for kmem_arena in vmem.

Reviewed by: alc
Tested by: pho
Sponsored by: EMC / Isilon Storage Division

show more ...


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

IFC @ r254014


# be996836 05-Aug-2013 Attilio Rao <attilio@FreeBSD.org>

Revert r253939:
We cannot busy a page before doing pagefaults.
Infact, it can deadlock against vnode lock, as it tries to vget().
Other functions, right now, have an opposite lock ordering, like
vm_o

Revert r253939:
We cannot busy a page before doing pagefaults.
Infact, it can deadlock against vnode lock, as it tries to vget().
Other functions, right now, have an opposite lock ordering, like
vm_object_sync(), which acquires the vnode lock first and then
sleeps on the busy mechanism.

Before this patch is reinserted we need to break this ordering.

Sponsored by: EMC / Isilon storage division
Reported by: kib

show more ...


# 3b6714ca 04-Aug-2013 Attilio Rao <attilio@FreeBSD.org>

The page hold mechanism is fast but it has couple of fallouts:
- It does not let pages respect the LRU policy
- It bloats the active/inactive queues of few pages

Try to avoid it as much as possible

The page hold mechanism is fast but it has couple of fallouts:
- It does not let pages respect the LRU policy
- It bloats the active/inactive queues of few pages

Try to avoid it as much as possible with the long-term target to
completely remove it.
Use the soft-busy mechanism to protect page content accesses during
short-term operations (like uiomove_fromphys()).

After this change only vm_fault_quick_hold_pages() is still using the
hold mechanism for page content access.
There is an additional complexity there as the quick path cannot
immediately access the page object to busy the page and the slow path
cannot however busy more than one page a time (to avoid deadlocks).

Fixing such primitive can bring to complete removal of the page hold
mechanism.

Sponsored by: EMC / Isilon storage division
Discussed with: alc
Reviewed by: jeff
Tested by: pho

show more ...


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

IFC @253398


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

Merge fresh head.


# 995d7069 08-Jun-2013 Gleb Smirnoff <glebius@FreeBSD.org>

Make sys_mlock() function just a wrapper around vm_mlock() function
that does all the job.

Reviewed by: kib, jilles
Sponsored by: Nginx, Inc.


12345678910>>...13