#
a626bdab |
|
29-May-2020 |
Michael Lotz <mmlr@mlotz.ch> |
kernel/vm: Remove linear search from _get_next_area_info. This introduces VMAddressSpace::FindClosestArea() that can be used to find the closest area to a given address in either direction. This is now trivial and efficient since both kernel and user address spaces use a binary search tree. Using FindClosestArea() getting multiple area infos is sped up dramatically as it removes the need for a linear search from the first area to the one given in the cookie on each successive invocation. Change-Id: I227da87d915f6f3d3ef88bfeb6be5d4c97c3baaa Reviewed-on: https://review.haiku-os.org/c/haiku/+/2840 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
951c43ff |
|
02-Nov-2011 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Allocate VMKernelAddressRange and VMKernelArea in their own object caches to reduce slab area fragmentation. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43136 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a8ad734f |
|
14-Jun-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Introduced structures {virtual,physical}_address_restrictions, which specify restrictions for virtual/physical addresses. * vm_page_allocate_page_run(): - Fixed conversion of base/limit to array indexes. sPhysicalPageOffset was not taken into account. - Takes a physical_address_restrictions instead of base/limit and also supports alignment and boundary restrictions, now. * map_backing_store(), VM[User,Kernel]AddressSpace::InsertArea()/ ReserveAddressRange() take a virtual_address_restrictions parameter, now. They also support an alignment independent from the range size. * create_area_etc(), vm_create_anonymous_area(): Take {virtual,physical}_address_restrictions parameters, now. * Removed no longer needed B_PHYSICAL_BASE_ADDRESS. * DMAResources: - Fixed potential overflows of uint32 when initializing from device node attributes. - Fixed bounce buffer creation TODOs: By using create_area_etc() with the new restrictions parameters we can directly support physical high address, boundary, and alignment. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37131 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
deee8524 |
|
26-Jan-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Introduced {malloc,memalign,free}_etc() which take an additional "flags" argument. They replace the previous special-purpose allocation functions (malloc_nogrow(), vip_io_request_malloc()). * Moved the I/O VIP heap to heap.cpp accordingly. * Added quite a bit of passing around of allocation flags in the VM, particularly in the VM*AddressSpace classes. * Fixed IOBuffer::GetNextVirtualVec(): It was ignoring the VIP flag and always allocated on the normal heap. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35316 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
40cd019e |
|
06-Dec-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Renamed VMAddressSpace::ResizeArea{Head,Tail}() to ShrinkArea{Head,Tail}() to clarify that they never enlarge the area. * Reimplemented VMKernelAddressSpace. It is somewhat inspired by Bonwick's vmem resource allocator (though we have different requirements): - We consider the complete address space to be divided into contiguous ranges of type free, reserved, or area, each range being represented by a VMKernelAddressRange object. - The range objects are managed in an AVL tree and a doubly linked list (the latter only for faster iteration) sorted by address. This provides O(log(n)) lookup, insertion and removal. - For each power of two size we maintain a list of free ranges of at least that size. Thus for the most common case of B_ANY*_ADDRESS area allocation, we find a free range in constant time (the rest of the processing being O(log(n))) with a rather good fit. This should also help avoiding address space fragmentation. While the new implementation should be faster, particularly with an increasing number of areas, I couldn't measure any difference in the -j2 haiku build. From a cursory test the -j8 build hasn't tangibly benefitted either. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34528 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2c1886ae |
|
04-Dec-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Added VMArea subclasses VM{Kernel,User}Area and moved the address space list link to them. * VM{Kernel,User}AddressSpace manage the respective VMArea subclass now, and VMAddressSpace has grown factory methods {Create,Delete}Area. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34493 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e2518ddb |
|
04-Dec-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Made VMAddressSpace an abstract base class and moved the area management into new derived classes VM{Kernel,User}AddressSpace. Currently those are identical, but that will change. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34492 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
951c43ff21cd27855e8001c8fc53dd57d02b51fb |
|
02-Nov-2011 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Allocate VMKernelAddressRange and VMKernelArea in their own object caches to reduce slab area fragmentation. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43136 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a8ad734f1c698917badb15e1641e0f38b3e9a013 |
|
14-Jun-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Introduced structures {virtual,physical}_address_restrictions, which specify restrictions for virtual/physical addresses. * vm_page_allocate_page_run(): - Fixed conversion of base/limit to array indexes. sPhysicalPageOffset was not taken into account. - Takes a physical_address_restrictions instead of base/limit and also supports alignment and boundary restrictions, now. * map_backing_store(), VM[User,Kernel]AddressSpace::InsertArea()/ ReserveAddressRange() take a virtual_address_restrictions parameter, now. They also support an alignment independent from the range size. * create_area_etc(), vm_create_anonymous_area(): Take {virtual,physical}_address_restrictions parameters, now. * Removed no longer needed B_PHYSICAL_BASE_ADDRESS. * DMAResources: - Fixed potential overflows of uint32 when initializing from device node attributes. - Fixed bounce buffer creation TODOs: By using create_area_etc() with the new restrictions parameters we can directly support physical high address, boundary, and alignment. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37131 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
deee8524b7534d9b586cbcbf366d0660c9769a8e |
|
26-Jan-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Introduced {malloc,memalign,free}_etc() which take an additional "flags" argument. They replace the previous special-purpose allocation functions (malloc_nogrow(), vip_io_request_malloc()). * Moved the I/O VIP heap to heap.cpp accordingly. * Added quite a bit of passing around of allocation flags in the VM, particularly in the VM*AddressSpace classes. * Fixed IOBuffer::GetNextVirtualVec(): It was ignoring the VIP flag and always allocated on the normal heap. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35316 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
40cd019ea0415011db2a82c736e716a22ca842cc |
|
06-Dec-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Renamed VMAddressSpace::ResizeArea{Head,Tail}() to ShrinkArea{Head,Tail}() to clarify that they never enlarge the area. * Reimplemented VMKernelAddressSpace. It is somewhat inspired by Bonwick's vmem resource allocator (though we have different requirements): - We consider the complete address space to be divided into contiguous ranges of type free, reserved, or area, each range being represented by a VMKernelAddressRange object. - The range objects are managed in an AVL tree and a doubly linked list (the latter only for faster iteration) sorted by address. This provides O(log(n)) lookup, insertion and removal. - For each power of two size we maintain a list of free ranges of at least that size. Thus for the most common case of B_ANY*_ADDRESS area allocation, we find a free range in constant time (the rest of the processing being O(log(n))) with a rather good fit. This should also help avoiding address space fragmentation. While the new implementation should be faster, particularly with an increasing number of areas, I couldn't measure any difference in the -j2 haiku build. From a cursory test the -j8 build hasn't tangibly benefitted either. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34528 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2c1886aeae1be8dc6bb9656701b2aab5bf3311ca |
|
04-Dec-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Added VMArea subclasses VM{Kernel,User}Area and moved the address space list link to them. * VM{Kernel,User}AddressSpace manage the respective VMArea subclass now, and VMAddressSpace has grown factory methods {Create,Delete}Area. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34493 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e2518ddbb14677f379b8dc8f66088473c553b113 |
|
04-Dec-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Made VMAddressSpace an abstract base class and moved the area management into new derived classes VM{Kernel,User}AddressSpace. Currently those are identical, but that will change. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34492 a95241bf-73f2-0310-859d-f6bbb57e9c96
|