Searched +hist:24 +hist:df6592 (Results 101 - 101 of 101) sorted by relevance
| /haiku/src/system/kernel/vm/ | ||
| H A D | vm.cpp | 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 77034a15 Fri Mar 11 12:24:28 MST 2022 Augustin Cavalier <waddlesplash@gmail.com> kernel/vm: Let _user_set_memory_protection change area->protection if possible. If mprotect() is being run over an entire area, and the area does not have per-page protections, then we can just invoke set_area_protection instead of allocating a protections array. This is a major efficiency increase, as every page fault would otherwise have to use the protections array if it was allocated. Testing with QtWebEngine shows this new path being hit relatively often (multiple hundred times in loading a single webpage). Change-Id: I60258d56f681060861602922f3fbdbce2fd380d6 Reviewed-on: https://review.haiku-os.org/c/haiku/+/5097 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> diff a959262c Sat Dec 14 04:24:38 MST 2019 Adrien Destugues <pulkomandy@pulkomandy.tk> implement mlock(), munlock() Change-Id: I2f04b8986d2ed32bb4d30d238d668e21a1505778 Reviewed-on: https://review.haiku-os.org/c/haiku/+/1991 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> diff 928d780b Sun May 24 16:09:42 MDT 2020 Michael Lotz <mmlr@mlotz.ch> kernel/vm: Factor out intersect_area and use it for cut_area. It combines the intersection check and setting address, size and offset so that they fall within the area. Change-Id: Iffd3feca75d4e6389d23b9d70294253b4c3d1f4c Reviewed-on: https://review.haiku-os.org/c/haiku/+/2837 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff 4986a9a3 Sun May 24 14:14:09 MDT 2020 Michael Lotz <mmlr@mlotz.ch> Revert "kernel: Remove the B_KERNEL_AREA protection flag." This reverts parts of hrev52546 that removed the B_KERNEL_AREA protection flag and replaced it with an address space comparison. Checking for areas in the kernel address space inside a user address space does not work, as areas can only ever belong to one address space. This rendered these checks ineffective and allowed to unmap, delete or resize kernel managed areas from their respective userland teams. That protection was meant to be applied to the team user data area which was introduced to reduce the kernel to userland overhead by directly sharing some data between the two. It was intended to be set up in such a manner that this is safe on the kernel side and the B_KERNEL_AREA flag was introduced specifically for this purpose. Incidentally the actual application of the B_KERNEL_AREA flag on the team user data area was apparently forgotten in the original commit. The absence of that protection allowed applications to induce KDLs by modifying the user area and generating a signal for example. This change restores the B_KERNEL_AREA flag and also applies it to the team user data area. Change-Id: I993bb1cf7c6ae10085100db7df7cc23fe66f4edd Reviewed-on: https://review.haiku-os.org/c/haiku/+/2836 Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff da73ed96 Sat Aug 10 17:49:24 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> kernel/vm: Enable area-cloning protection for userland areas, too. We allow teams to clone areas within themselves, but I'm not sure exactly what use that has. The kernel can of course clone anything it wants to, still. Hopefully this will prove substantially less disruptive than the reverse change last year, as the preceding commits are likely the only major consumers of this API, rather than a variety of drivers that need to be individually tested. diff b521a45e Tue Dec 13 02:24:12 MST 2016 Jessica Hamilton <jessica.l.hamilton@gmail.com> Revert "vm: Try harder to allocate early physical pages." This reverts commit 21e3ac6cf52f91dba8217f15fc33dc1d45dffd40, which was accidentally applied twice, missed during rebase. Originally applied in 601b2f7eda4d25b46e7d17e212d22954f28bd0fe. diff c1517626 Fri Jul 06 08:24:02 MDT 2012 Alex Smith <alex@alex-smith.me.uk> Compile APIC and timer code for x86_64, and create an area for the IDT. diff f1244978 Fri Jun 22 12:24:51 MDT 2012 Alex Smith <alex@alex-smith.me.uk> Added an ELF64 version of preloaded_image. * There is now 2 structures, preloaded_elf32_image and preloaded_elf64_image, which both inherit from preloaded_image. * For now I've just hardcoded in use of preloaded_elf32_image, but the bootloader ELF code will shortly be converted to use templates which use the appropriate structure. The kernel will be changed later when I add ELF64 support to it. * All kernel_args data is now compatible between 32-bit and 64-bit kernels. |
Completed in 286 milliseconds