Searched +hist:1 +hist:b6eff28 (Results 1 - 7 of 7) sorted by relevance

/haiku/headers/private/system/
H A Dvm_defs.hdiff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff280f4afcf4d7c9dc9ccdc3a65f4e6ca0fd Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/system/kernel/arch/generic/
H A Dgeneric_vm_physical_page_mapper.cppdiff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff280f4afcf4d7c9dc9ccdc3a65f4e6ca0fd Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/system/kernel/arch/ppc/
H A Darch_vm_translation_map.cppdiff 1ba89e67 Sat Jun 05 16:20:34 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Removed no-op VMTranslationMap::InitPostSem() and
VMAddressSpace::InitPostSem().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37025 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1ba89e67eda21e7ad9e1ec57a53ae0a3436b8721 Sat Jun 05 16:20:34 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Removed no-op VMTranslationMap::InitPostSem() and
VMAddressSpace::InitPostSem().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37025 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff280f4afcf4d7c9dc9ccdc3a65f4e6ca0fd Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/system/kernel/arch/x86/
H A Darch_vm_translation_map.cppdiff 1b3e83ad Tue Jun 08 09:00:56 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Moved paging related files to new subdirectories paging and paging/32bit.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37060 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1ba89e67 Sat Jun 05 16:20:34 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Removed no-op VMTranslationMap::InitPostSem() and
VMAddressSpace::InitPostSem().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37025 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1a053eed Tue Sep 08 10:24:43 MDT 2009 Michael Lotz <mmlr@mlotz.ch> Revert r32994 and add a comment to explain the intention. Thanks Ingo for the
clarification.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33001 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1c8de858 Sun Jun 01 20:04:12 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Added optional spinlock contention measurement feature. Enabled when
B_DEBUG_SPINLOCK_CONTENTION is defined to 1. It typedefs spinlock to a
structure (thus breaking BeOS binary compatibility), containing a
counter which is incremented whenever a thread has to wait for the
spinlock.
* Added macros for spinlock initialization and access and changed
code using spinlocks accordingly. This breaks compilation for BeOS --
the macros should be defined in the respective compatibility wrappers.
* Added generic syscall to get the spinlock counters for the thread and
the team spinlocks.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25752 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1c8de858 Sun Jun 01 20:04:12 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Added optional spinlock contention measurement feature. Enabled when
B_DEBUG_SPINLOCK_CONTENTION is defined to 1. It typedefs spinlock to a
structure (thus breaking BeOS binary compatibility), containing a
counter which is incremented whenever a thread has to wait for the
spinlock.
* Added macros for spinlock initialization and access and changed
code using spinlocks accordingly. This breaks compilation for BeOS --
the macros should be defined in the respective compatibility wrappers.
* Added generic syscall to get the spinlock counters for the thread and
the team spinlocks.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25752 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b3e83addefd97925b84cebaf4003d14c9062781 Tue Jun 08 09:00:56 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Moved paging related files to new subdirectories paging and paging/32bit.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37060 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1ba89e67eda21e7ad9e1ec57a53ae0a3436b8721 Sat Jun 05 16:20:34 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Removed no-op VMTranslationMap::InitPostSem() and
VMAddressSpace::InitPostSem().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37025 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1a053eedc0801705aff5e53c01ddb571f035c672 Tue Sep 08 10:24:43 MDT 2009 Michael Lotz <mmlr@mlotz.ch> Revert r32994 and add a comment to explain the intention. Thanks Ingo for the
clarification.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33001 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/system/kernel/cache/
H A Dfile_cache.cppdiff 1d578e15 Wed Jun 02 14:46:49 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Fixed more address types related issues. Mostly printf() or comparison
warnings, but also some oversights from earlier changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37000 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1f611c01 Tue Feb 16 10:22:56 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> The file cache code was completely ignoring the vm_page::modified flag. In
particular it wouldn't set the flag when writing something to a page, but
only move it to the modified queue. Since mapping the page would move it to
another queue, the information that the page was modified would be lost and
it would never be written to disk. Was well reproducible with a Haiku image
build and limited amount of memory.
Fixes the hopefully last remaining cause for #5374.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35500 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1af7d115 Sat Oct 10 16:37:26 MDT 2009 Michael Lotz <mmlr@mlotz.ch> * Rework page writing to combine page writes where possible. For now the pages
are required to be physically contiguos, which should be reworked to put them
into seperate iovecs. Still this manages to combine a great deal of page
writes into larger bursts already. Reduces the amount of IO requests being
scheduled (and greatly benefits media where page wise writes are slow when
they are accessed through a non-IOScheduler path, i.e. USB mass storage until
that is properly implemented).
* Abstracted per page page writing tasks into a PageWriteWrapper class.
* Abstracted per transfer page writing tasks into PageWriteTransfer class which
formerly was the PageWriterCallback.
* Use both classes from the PageWriterRun and from
vm_page_write_modified_page_range to remove code duplication.
* Adjusted synchronous VMAnonymousCache::Write() to cope correctly with larger
iovecs and more than one iovec. It assumed that there was exactly one page per
vector previously.
* Introduced MaxPagesPerWrite() and MaxPagesPerAsyncWrite() to VMCache to allow
a cache to specify restricitions. VMAnonymousCache does restrict the max pages
to 1 for WriteAsync right now as I didn't feel like reworking that one to cope
with non single page writes just yet.
* Pulled out PageWriteTransfer methods for better readability.
* Some typo fixes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33507 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1af7d115 Sat Oct 10 16:37:26 MDT 2009 Michael Lotz <mmlr@mlotz.ch> * Rework page writing to combine page writes where possible. For now the pages
are required to be physically contiguos, which should be reworked to put them
into seperate iovecs. Still this manages to combine a great deal of page
writes into larger bursts already. Reduces the amount of IO requests being
scheduled (and greatly benefits media where page wise writes are slow when
they are accessed through a non-IOScheduler path, i.e. USB mass storage until
that is properly implemented).
* Abstracted per page page writing tasks into a PageWriteWrapper class.
* Abstracted per transfer page writing tasks into PageWriteTransfer class which
formerly was the PageWriterCallback.
* Use both classes from the PageWriterRun and from
vm_page_write_modified_page_range to remove code duplication.
* Adjusted synchronous VMAnonymousCache::Write() to cope correctly with larger
iovecs and more than one iovec. It assumed that there was exactly one page per
vector previously.
* Introduced MaxPagesPerWrite() and MaxPagesPerAsyncWrite() to VMCache to allow
a cache to specify restricitions. VMAnonymousCache does restrict the max pages
to 1 for WriteAsync right now as I didn't feel like reworking that one to cope
with non single page writes just yet.
* Pulled out PageWriteTransfer methods for better readability.
* Some typo fixes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33507 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff ea2cd27e Wed Dec 21 10:00:03 MST 2005 Axel Dörfler <axeld@pinc-software.de> * Fixed the strange vm_cache_ref reference count mechanism: now, a fresh
vm_cache_ref starts with a reference count of 1. When acquiring a vm_cache,
you no longer need to worry if that should go through the vm_store, or not;
as it now always does.
* map_backing_store() no longer needs to play with the vm_cache_ref
references.
* that simplified some code.
* vfs_get_vnode_cache() now grabs a reference to the cache, if successful.
* better balanced vnode ownership on vnode_store creation (vnode_store
released the vnode before if its creation failed).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15641 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1c88c851 Wed Oct 19 17:01:57 MDT 2005 Axel Dörfler <axeld@pinc-software.de> Turned off debug output again - also temporarily removed the file cache warning
about our block_io module not honouring the total length in read_pages().
Removed drops into the debugger when there is a block without an "original"
data buffer - that's completely normal and happens when someone asks for
a cleared block that is not yet in the cache.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14437 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1d578e15fe5b5c3ff62866ae81aef529d00d7762 Wed Jun 02 14:46:49 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Fixed more address types related issues. Mostly printf() or comparison
warnings, but also some oversights from earlier changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37000 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1f611c018b474c78f84ea905e574c24586ae85b1 Tue Feb 16 10:22:56 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> The file cache code was completely ignoring the vm_page::modified flag. In
particular it wouldn't set the flag when writing something to a page, but
only move it to the modified queue. Since mapping the page would move it to
another queue, the information that the page was modified would be lost and
it would never be written to disk. Was well reproducible with a Haiku image
build and limited amount of memory.
Fixes the hopefully last remaining cause for #5374.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35500 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/system/kernel/vm/
H A Dvm_page.cppdiff be1cc9c8 Sat Jun 20 15:07:03 MDT 2020 Augustin Cavalier <waddlesplash@gmail.com> kernel/vm: Make the page_scrubber wait on a condition.

On an idle system with 1GB RAM and the 100ms timeout, it takes multiple
minutes for all the pages in the system to get cleared after boot, but once
they do, the page scrubber will then remain idle for seconds to even
minutes at a time, so this is clearly worth it.

The "free pages condition" was unused before this commit, so I have
repurposed it (and unpublished it.)

Change-Id: I7034677a1e51c97c2baf11b772db3a31c0e1adfa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1699
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 1d26c724 Thu Jun 10 11:30:49 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> vm_page_allocate_page_run(): Added parameter "limit", specifying the upper
physical address limit for the page run to allocate.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37086 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1d578e15 Wed Jun 02 14:46:49 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Fixed more address types related issues. Mostly printf() or comparison
warnings, but also some oversights from earlier changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37000 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1e175b59 Sun Jan 03 18:09:58 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Removed duplicate condition.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34886 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1af7d115 Sat Oct 10 16:37:26 MDT 2009 Michael Lotz <mmlr@mlotz.ch> * Rework page writing to combine page writes where possible. For now the pages
are required to be physically contiguos, which should be reworked to put them
into seperate iovecs. Still this manages to combine a great deal of page
writes into larger bursts already. Reduces the amount of IO requests being
scheduled (and greatly benefits media where page wise writes are slow when
they are accessed through a non-IOScheduler path, i.e. USB mass storage until
that is properly implemented).
* Abstracted per page page writing tasks into a PageWriteWrapper class.
* Abstracted per transfer page writing tasks into PageWriteTransfer class which
formerly was the PageWriterCallback.
* Use both classes from the PageWriterRun and from
vm_page_write_modified_page_range to remove code duplication.
* Adjusted synchronous VMAnonymousCache::Write() to cope correctly with larger
iovecs and more than one iovec. It assumed that there was exactly one page per
vector previously.
* Introduced MaxPagesPerWrite() and MaxPagesPerAsyncWrite() to VMCache to allow
a cache to specify restricitions. VMAnonymousCache does restrict the max pages
to 1 for WriteAsync right now as I didn't feel like reworking that one to cope
with non single page writes just yet.
* Pulled out PageWriteTransfer methods for better readability.
* Some typo fixes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33507 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1af7d115 Sat Oct 10 16:37:26 MDT 2009 Michael Lotz <mmlr@mlotz.ch> * Rework page writing to combine page writes where possible. For now the pages
are required to be physically contiguos, which should be reworked to put them
into seperate iovecs. Still this manages to combine a great deal of page
writes into larger bursts already. Reduces the amount of IO requests being
scheduled (and greatly benefits media where page wise writes are slow when
they are accessed through a non-IOScheduler path, i.e. USB mass storage until
that is properly implemented).
* Abstracted per page page writing tasks into a PageWriteWrapper class.
* Abstracted per transfer page writing tasks into PageWriteTransfer class which
formerly was the PageWriterCallback.
* Use both classes from the PageWriterRun and from
vm_page_write_modified_page_range to remove code duplication.
* Adjusted synchronous VMAnonymousCache::Write() to cope correctly with larger
iovecs and more than one iovec. It assumed that there was exactly one page per
vector previously.
* Introduced MaxPagesPerWrite() and MaxPagesPerAsyncWrite() to VMCache to allow
a cache to specify restricitions. VMAnonymousCache does restrict the max pages
to 1 for WriteAsync right now as I didn't feel like reworking that one to cope
with non single page writes just yet.
* Pulled out PageWriteTransfer methods for better readability.
* Some typo fixes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33507 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1b6eff28 Sat Oct 11 14:55:32 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Replaced the vm_get_physical_page() "flags"
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 6bf15ffc Sun Apr 27 08:24:18 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Changed macros that enable tracing for individual components from
defined/undefined to numeric values (0 for undefined). This allows for
trace levels.
* Set SYSCALL_TRACING_IGNORE_KTRACE_OUTPUT default to 1, since this is
what one usually wants.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25213 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1d26c7248fcd916adadc03b5fd59cfc4f2adfaa5 Thu Jun 10 11:30:49 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> vm_page_allocate_page_run(): Added parameter "limit", specifying the upper
physical address limit for the page run to allocate.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37086 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A Dvm.cppdiff c650846d Tue Mar 14 15:42:25 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> vm: Replace the VMAreas OpenHashTable with an AVLTree.

Since we used a hash table with a fixed size (1024), collisions were
obviously inevitable, meaning that while insertions would always be
fast, lookups and deletions would take linear time to search the
linked-list for the area in question. For recently-created areas,
this would be fast; for less-recently-created areas, it would get
slower and slower and slower.

A particularly pathological case was the "mmap/24-1" test from the
Open POSIX Testsuite, which creates millions of areas until it hits
ENOMEM; it then simply exits, at which point it would run for minutes
and minutes in the kernel team deletion routines; how long I don't know,
as I rebooted before it finished.

This change fixes that problem, among others, at the cost of increased
area creation time, by using an AVL tree instead of a hash. For comparison,
mmap'ing 2 million areas with the "24-1" test before this change took
around 0m2.706s of real time, while afterwards it takes about 0m3.118s,
or around a 15% increase (1.152x).

On the other hand, the total test runtime for 2 million areas went from
around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other
words, with this new code, it is *32 times faster.*

Area insertion will no longer be O(1), however, so the time increase
may go up with the number of areas present on the system; but if it's
only around 3 seconds to create 2 million areas, or about 1.56 us per area,
vs. 1.35 us before, I don't think that's worth worrying about.

My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark
seems to be within the realm of "noise", anyway, with most results
both before and after this change coming in around 47s real time.

Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831
diff c650846d Tue Mar 14 15:42:25 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> vm: Replace the VMAreas OpenHashTable with an AVLTree.

Since we used a hash table with a fixed size (1024), collisions were
obviously inevitable, meaning that while insertions would always be
fast, lookups and deletions would take linear time to search the
linked-list for the area in question. For recently-created areas,
this would be fast; for less-recently-created areas, it would get
slower and slower and slower.

A particularly pathological case was the "mmap/24-1" test from the
Open POSIX Testsuite, which creates millions of areas until it hits
ENOMEM; it then simply exits, at which point it would run for minutes
and minutes in the kernel team deletion routines; how long I don't know,
as I rebooted before it finished.

This change fixes that problem, among others, at the cost of increased
area creation time, by using an AVL tree instead of a hash. For comparison,
mmap'ing 2 million areas with the "24-1" test before this change took
around 0m2.706s of real time, while afterwards it takes about 0m3.118s,
or around a 15% increase (1.152x).

On the other hand, the total test runtime for 2 million areas went from
around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other
words, with this new code, it is *32 times faster.*

Area insertion will no longer be O(1), however, so the time increase
may go up with the number of areas present on the system; but if it's
only around 3 seconds to create 2 million areas, or about 1.56 us per area,
vs. 1.35 us before, I don't think that's worth worrying about.

My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark
seems to be within the realm of "noise", anyway, with most results
both before and after this change coming in around 47s real time.

Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831
diff c650846d Tue Mar 14 15:42:25 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> vm: Replace the VMAreas OpenHashTable with an AVLTree.

Since we used a hash table with a fixed size (1024), collisions were
obviously inevitable, meaning that while insertions would always be
fast, lookups and deletions would take linear time to search the
linked-list for the area in question. For recently-created areas,
this would be fast; for less-recently-created areas, it would get
slower and slower and slower.

A particularly pathological case was the "mmap/24-1" test from the
Open POSIX Testsuite, which creates millions of areas until it hits
ENOMEM; it then simply exits, at which point it would run for minutes
and minutes in the kernel team deletion routines; how long I don't know,
as I rebooted before it finished.

This change fixes that problem, among others, at the cost of increased
area creation time, by using an AVL tree instead of a hash. For comparison,
mmap'ing 2 million areas with the "24-1" test before this change took
around 0m2.706s of real time, while afterwards it takes about 0m3.118s,
or around a 15% increase (1.152x).

On the other hand, the total test runtime for 2 million areas went from
around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other
words, with this new code, it is *32 times faster.*

Area insertion will no longer be O(1), however, so the time increase
may go up with the number of areas present on the system; but if it's
only around 3 seconds to create 2 million areas, or about 1.56 us per area,
vs. 1.35 us before, I don't think that's worth worrying about.

My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark
seems to be within the realm of "noise", anyway, with most results
both before and after this change coming in around 47s real time.

Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831
diff c25f6f53 Tue Mar 29 18:09:36 MDT 2022 Augustin Cavalier <waddlesplash@gmail.com> kernel/vm: Completely replace mlock() implementation.

The old implementation used the real lock_memory(). This is problematic
and does not work for a large number of reasons:

1) Various parts of the kernel assume memory is locked only very
temporarily, and will often wait on locked memory to become unlocked.
The transient nature of locks is further demonstrated by the fact that
lock_memory acquires references to structures, like the address space,
which are only released by unlock_memory

2) The VM has a hard assumption that all lock_memory calls will be
exactly balanced, and maintains internal "WiredRange" structures
on areas, etc. corresponding to the original lock_memory calls.
Maintaining separate data structures as this code did is a recipe
for even more problems when the structures are manipulated separately,
leading to confusing or incorrect behavior on unlocks.

3) Areas with locked memory cannot be deleted, nor can the pages which are
locked be removed from the areas/caches. This of course is most notable
when destroying teams which locked memory, but the problem also occurs
when just using delete_area, resize_area, mmap/munmap, etc.

Because of (2) and especially (3), adding support for mlock()-like semantics
to the existing memory locking system is just not a good option. A further
reason is that our lock_memory is much stricter than mlock(), which only
demands the pages in question must remain resident in RAM and cannot be
swapped out (or, it seems, otherwise written back to disk.)

Thus, this commit completely removes the old implementation (which
was seriously broken and did not actually automatically unlock memory
on team exit or area destruction at all, etc.) and instead adds a new
feature to VMAnonymousCache to block certain pages from being written out.
The syscall then just invokes this to do its work.

Fixes #17674. Related to #13651.

Change-Id: Id2745c51796bcf9a74ba5325fe686a95623cd521
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5147
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 8ca0f03d Mon Nov 08 23:39:16 MST 2021 X512 <danger_mail@list.ru> riscv64/smp: Implement multi-processor support

* Working under qemu smp 1,2+
* Working on SiFive Unmatched
* x86_64 efi not broken by smp_boot_other_cpus change

Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
diff 1e3d4cf7 Sat Mar 21 20:26:44 MDT 2020 X512 <danger_mail@list.ru> Kernel: remove dead code

area->name is a fixed array inside struct, not pointer, so it should
be never be NULL.

Pointed by clang.

Change-Id: Ic8930450cb8461eef158bc854f214eb47d92ce22
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2391
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
diff 023a547d Mon Aug 06 21:27:50 MDT 2018 Augustin Cavalier <waddlesplash@gmail.com> vm: Enable B_USER_CLONEABLE_AREA protection.

Spotted while reading through the VM code while thinking about how to
implement vfork().

When axeld disabled this in 2005 (!), Haiku's kernel was still young,
BeOS drivers were still "a thing," and there was no distinction in this
function from being called by the kernel / not by the kernel.

Now, it's 2018, we manage all drivers ourselves, have SMAP enabled by
default when available, and as axeld recently noted on the mailing lists,
"there's not much reason we still use GCC2 for the kernel anyway." So we
probably don't care about any BeOS drivers that may be broken by this
(are there any still around?)

Besides the usual fixes to get this 13-year-old chunk to work again, there
are two functional changes:
1) Allow the kernel to clone whatever it likes into the user's address space.
It seems that this is often done legitimately (e.g. team creation), and
so attempting to distinguish those cases seems more work than it may be
worth right now.

The disadvantage is that drivers without proper checks may be "tricked"
into cloning areas they shouldn't; but I'm guessing if that's the case,
then something else is probably broken and the driver should be fixed.
It seems the reverse case (cloning a userland area into the kernel)
is much more common (in fact, it looks like all 4 of the 4 places
where clone_area is used in kernel-space outside the kernel itself
are doing this.)

2) At KDEBUG_LEVEL 2 and higher, throw a panic when attempting to clone
an area that does not have the protection flag set. This should make
finding any bugs exposed by this change much easier than "hardware doesn't
work" / "black screen on boot" / etc., as well as any potential future
bugs introduced in the process of driver development.
diff 70d3bd55 Tue Oct 28 17:53:06 MDT 2014 Ingo Weinhold <ingo_weinhold@gmx.de> vm_soft_fault(): Missing DEBUG_PAGE_ACCESS_END()

... in case we'd need to unmap a page that is wired.

Fixes the immediate issue of #10977. There's a problem remaining (as
discussed in comment 1): If two threads want to wire the same page at
the same time (which led to the assertion being triggered), they will
now deadlock, waiting for each other to remove the pre-registered
VMAreaWiredRange.
diff 1fe24d0c Sat Dec 03 12:03:20 MST 2011 Michael Lotz <mmlr@mlotz.ch> Add heap with guard pages to detect out of bound reads/writes.

This is a very simple heap implementation that allocates memory so that
the end of each allocation always coincides with a page end and is
followed by a guard page which is marked non-present. Out of bounds
access (both read and write) therefore cause a crash (unhandled page
fault).

Note that this allocator is neither speed nor space efficient, indeed it
wastes huge amounts of pages and address space so it is quite easy to
hit limits. It is intended as a pure debug feature.
diff 1d26c724 Thu Jun 10 11:30:49 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> vm_page_allocate_page_run(): Added parameter "limit", specifying the upper
physical address limit for the page run to allocate.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37086 a95241bf-73f2-0310-859d-f6bbb57e9c96

Completed in 472 milliseconds