Searched +hist:20 +hist:b232e9 (Results 1 - 2 of 2) sorted by relevance
/haiku/src/system/kernel/cache/ | ||
H A D | file_cache.cpp | diff 425ac1b6 Tue Jun 20 16:57:22 MDT 2023 Alexander von Gluck IV <kallisti5@unixzen.com> refactor: Swap %Ld for %lld in all format usages * %Ld is an undocumented alias for %lld in glibc. * muslc doesn't implement it for this reason. * While we will likely never drop %Ld support, lets clean house and set a better example. Change-Id: Id46dad3104abae483e80cc5c05d1464d3ecd8030 Reviewed-on: https://review.haiku-os.org/c/haiku/+/6636 Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> diff b344d252 Sat Jun 20 15:21:56 MDT 2020 Augustin Cavalier <waddlesplash@gmail.com> kernel/file_cache: Move write_zeros_... call out of else. Style only, no functional change. Requested by axeld. diff 435c43f5 Wed Jun 02 12:42:20 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Introduced type generic_io_vec, which is similar to iovec, but uses types that are wide enough for both virtual and physical addresses. * DMABuffer, IORequest, IOScheduler,... and code using them: Use generic_io_vec and generic_{addr,size}_t where necessary. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36997 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bd7645a1 Sat Feb 20 08:57:44 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Made vm_page::state private and added accessor methods. * Added kernel tracing for page state transitions. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35538 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9824ded0 Sat Feb 20 03:51:53 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> cache_io(): Also requeue the last touched page to keep things roughly LRU sorted. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35530 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8a26f35a Mon Apr 20 02:02:51 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Sequential write accesses were never detected, due to an incorrect check. * The previous code would have scheduled a single page to be written out (if it would have ever been triggered), now we schedule the complete previous write access. This greatly speeds up a "dd if=/dev/zero of=test ..." beyond the size of available memory. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30276 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 47c40a10 Sun Oct 19 18:06:09 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> * Prefixed memset_physical() and memcpy_to_physical() with "vm_", added vm_memcpy_from_physical() and vm_memcpy_physical_page(), and added respective functions to the vm_translation_map operations. The architecture specific implementation can now decide how to implement them most efficiently. Added generic implementations that can be used, though. * Changed vm_{get,put}_physical_page(). The former no longer accepts flags (the only flag PHYSICAL_PAGE_DONT_WAIT wasn't needed anymore). Instead it returns an implementation-specific handle that has to be passed to the latter. Added vm_{get,put}_physical_page_current_cpu() and *_debug() variants, that work only for the current CPU, respectively when in the kernel debugger. Also adjusted the vm_translation_map operations accordingly. * Made consequent use of the physical memory operations in the source tree. * Also adjusted the m68k and ppc implementations with respect to the vm_translation_map operation changes, but they are probably broken, nevertheless. * For x86 the generic physical page mapper isn't used anymore. It is suboptimal in any case. For systems with small memory it is too much overhead, since one can just map the complete physical memory (that's not done yet, though). For systems with large memory it counteracts the VM strategy to reuse the least recently used pages. Since those pages will most likely not be mapped by the page mapper anymore, it will keep remapping chunks. This was also the reason why building Haiku in Haiku was significantly faster with only 256 MB RAM (since that much could be kept mapped all the time). Now we're using a different strategy: We have small pools of virtual page slots per CPU that are used for the physical page operations (memset_physical(), memcpy_*_physical()) with CPU-pinned thread. Furthermore we have four slots per translation map, which are used to map page tables. These changes speed up the Haiku image build in Haiku significantly. On my Core2 Duo 2.2 GHz 2 GB machine about 40% to 20 min 40 s (KDEBUG disabled, block cache debug disabled). Still more than factor 3 slower than FreeBSD and Linux, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28244 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 0d871d3c Mon Oct 08 20:04:36 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * satisfy_cache_io() was using the wrong value to compute the number of pages to reserve, which could result in to few being reserved in certain situations. * Use MutexLocker where appropriate. * Reordered includes following the new rules. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22494 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 20b232e9 Sun Oct 07 07:32:13 MDT 2007 Axel Dörfler <axeld@pinc-software.de> Actually forgot this nail: the file cache will now reserve the pages it will allocate with the vm_cache locked - this is necessary to be able to steal pages from itself (large files...). The system doesn't actually lock up anymore, but it still renders itself unusable; obviously the page thief does not work correctly, yet. The rest of the experience is created by our current scheduler (the page thief runs and runs, but it doesn't free any pages anymore). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22466 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 20b232e9 Sun Oct 07 07:32:13 MDT 2007 Axel Dörfler <axeld@pinc-software.de> Actually forgot this nail: the file cache will now reserve the pages it will allocate with the vm_cache locked - this is necessary to be able to steal pages from itself (large files...). The system doesn't actually lock up anymore, but it still renders itself unusable; obviously the page thief does not work correctly, yet. The rest of the experience is created by our current scheduler (the page thief runs and runs, but it doesn't free any pages anymore). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22466 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/system/kernel/vm/ | ||
H A D | vm_page.cpp | diff 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 d02aaee1 Sun Dec 15 20:53:46 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Add more memory info in system_info system_info now contains all information previously available only through __get_system_info_etc(B_MEMORY_INFO, ...). diff c8dd9f77 Tue Oct 29 20:58:36 MDT 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel: Add thread_unblock() and use it where possible diff 4be4fc6b Fri Jun 15 09:04:20 MDT 2012 Alex Smith <alex@alex-smith.me.uk> More 64-bit compilation/safety fixes. diff 435c43f5 Wed Jun 02 12:42:20 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Introduced type generic_io_vec, which is similar to iovec, but uses types that are wide enough for both virtual and physical addresses. * DMABuffer, IORequest, IOScheduler,... and code using them: Use generic_io_vec and generic_{addr,size}_t where necessary. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36997 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 24244d3c Sat Feb 20 10:24:14 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> idle_scan_active_pages(): vm_page_requeue() requires the caller to mark the page accessed for the access debugging feature. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35542 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 4a1f6683 Sat Feb 20 10:17:22 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Also print the page for the page related asserts. * Used vm_page::IsMapped() to simplify things. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35541 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 3e5343f2 Sat Feb 20 09:45:44 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> free_cached_page(): Removed incorrect asserts. The same ones appear a few lines later anyway, after the cache has been locked and it has been verified that the page is still a candidate. Fixes #5432. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35539 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bd7645a1 Sat Feb 20 08:57:44 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Made vm_page::state private and added accessor methods. * Added kernel tracing for page state transitions. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35538 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff bcc2c157 Wed Jan 13 20:26:12 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Refactored vm_translation_map: * Pulled the physical page mapping functions out of vm_translation_map into a new interface VMPhysicalPageMapper. * Renamed vm_translation_map to VMTranslationMap and made it a proper C++ class. The functions in the operations vector have become methods. * Added class GenericVMPhysicalPageMapper implementing VMPhysicalPageMapper as far as possible (without actually writing new code). * Adjusted the x86 and the PPC specifics accordingly (untested for the latter). For the other architectures the build is, I'm afraid, seriously broken. The next steps will modify and extend the VMTranslationMap interface, so that it will be possible to fix the bugs in vm_unmap_page[s]() and employ architecture specific optimizations. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35066 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 198 milliseconds