src-test2/sys/vm/vm_map.h, branch release/5.2.1_cvsFreeBSD source treehttps://cgit-dev.freebsd.org/src-test2/atom?h=release%2F5.2.1_cvs2004-02-23T15:32:56ZThis commit was manufactured by cvs2svn to create tag2004-02-23T15:32:56Zcvs2svncvs2svn@FreeBSD.org2004-02-23T15:32:56Zurn:sha1:84a7b99b4e02a260bf7ff9b540032f4cb7bc612a
'RELENG_5_2_1_RELEASE'.
This commit was manufactured to restore the state of the 5.2.1-RELEASE image.
Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs.
- Rename vm_map_clean() to vm_map_sync(). This better reflects the fact2003-11-09T05:25:35ZAlan Coxalc@FreeBSD.org2003-11-09T05:25:35Zurn:sha1:950f8459d4b081a7220d484e5447f4a13c39eb84
that msync(2) is its only caller.
- Migrate the parts of the old vm_map_clean() that examined the internals
of a vm object to a new function vm_object_sync() that is implemented in
vm_object.c. At the same, introduce the necessary vm object locking so
that vm_map_sync() and vm_object_sync() can be called without Giant.
Reviewed by: tegge
Whitespace cleanup.2003-11-03T16:14:45ZDag-Erling Smørgravdes@FreeBSD.org2003-11-03T16:14:45Zurn:sha1:a86fa8265955afe4650edbde13ee9dccb3a92668Move pmap_resident_count() from the MD pmap.h to the MI pmap.h.2003-10-06T01:47:12ZBruce M Simpsonbms@FreeBSD.org2003-10-06T01:47:12Zurn:sha1:2bc7dd566109712f59c836995384613c88bdd803
Add a definition of pmap_wired_count().
Add a definition of vmspace_wired_count().
Reviewed by: truckman
Discussed with: peter
Part 2 of implementing rstacks: add the ability to create rstacks and2003-09-27T22:28:14ZMarcel Moolenaarmarcel@FreeBSD.org2003-09-27T22:28:14Zurn:sha1:fd75d7104904b33cedbe568894dd6398d95f294d
use the ability on ia64 to map the register stack. The orientation of
the stack (i.e. its grow direction) is passed to vm_map_stack() in the
overloaded cow argument. Since the grow direction is represented by
bits, it is possible and allowed to create bi-directional stacks.
This is not an advertised feature, more of a side-effect.
Fix a bug in vm_map_growstack() that's specific to rstacks and which
we could only find by having the ability to create rstacks: when
the mapped stack ends at the faulting address, we have not actually
mapped the faulting address. we need to include or cover the faulting
address.
Note that at this time mmap(2) has not been extended to allow the
creation of rstacks by processes. If such a need arises, this can
be done.
Tested on: alpha, i386, ia64, sparc64
Introduce MAP_ENTRY_GROWS_DOWN and MAP_ENTRY_GROWS_UP to allow for2003-08-30T21:25:23ZMarcel Moolenaarmarcel@FreeBSD.org2003-08-30T21:25:23Zurn:sha1:b21a0008bac990d201c41aabefccd3eddaeaaae3
growable (stack) entries that not only grow down, but also grow up.
Have vm_map_growstack() take these flags into account when growing
an entry.
This is the first step in adding support for upward growable stacks.
It is a required feature on ia64 to support the register stack (or
rstack as I like to call it -- it also means reverse stack). We do
not currently create rstacks, so the upward growing is not exercised
and the change should be a functional no-op.
Reviewed by: alc
Reduce the size of the vm map (and by inclusion the vm space) on 64-bit2003-08-13T03:13:22ZAlan Coxalc@FreeBSD.org2003-08-13T03:13:22Zurn:sha1:46add1255282e96bf4b07a2eca2e3f01c3d9d4fc
architectures by moving a field within the structure.
Add the mlockall() and munlockall() system calls.2003-08-11T07:14:08ZBruce M Simpsonbms@FreeBSD.org2003-08-11T07:14:08Zurn:sha1:abd498aa7127b03d6c0593cdb8f8308dd65758c6
- All those diffs to syscalls.master for each architecture *are*
necessary. This needed clarification; the stub code generation for
mlockall() was disabled, which would prevent applications from
linking to this API (suggested by mux)
- Giant has been quoshed. It is no longer held by the code, as
the required locking has been pushed down within vm_map.c.
- Callers must specify VM_MAP_WIRE_HOLESOK or VM_MAP_WIRE_NOHOLES
to express their intention explicitly.
- Inspected at the vmstat, top and vm pager sysctl stats level.
Paging-in activity is occurring correctly, using a test harness.
- The RES size for a process may appear to be greater than its SIZE.
This is believed to be due to mappings of the same shared library
page being wired twice. Further exploration is needed.
- Believed to back out of allocations and locks correctly
(tested with WITNESS, MUTEX_PROFILING, INVARIANTS and DIAGNOSTIC).
PR: kern/43426, standards/54223
Reviewed by: jake, alc
Approved by: jake (mentor)
MFC after: 2 weeks
Introduce vm_map_pmap_enter(). Presently, this is a stub calling the MD2003-06-29T23:32:55ZAlan Coxalc@FreeBSD.org2003-06-29T23:32:55Zurn:sha1:0551c08dee67e09aed773c5ef20c7b59aada3922
pmap_object_init_pt().
Remove an unnecessary forward declaration.2003-06-15T07:28:33ZAlan Coxalc@FreeBSD.org2003-06-15T07:28:33Zurn:sha1:bf5f21b62294d48668109dacaa35f82e61deaa3b