Searched +hist:2 +hist:b028fca (Results 1 - 1 of 1) sorted by relevance
/haiku/src/system/kernel/cache/ | ||
H A D | file_cache.cpp | diff d5ad7629 Thu Apr 30 09:53:41 MDT 2009 Axel Dörfler <axeld@pinc-software.de> Fixed several problems of the prefetching code: * Did claim to have reserved pages when calling vm_page_allocate_page(), but didn't have any (copy&paste bug). We cannot use it without reserved pages, as we need to call vm_page_allocate_page() with a cache locked. * No longer use low_resource_state() to determine whether to precache or not, but use the new vm_page_num_used_pages() instead. * Also don't (try to) precache when the cache already has more than 2/3 of its pages to safe some unnecessary work. * The size to precache was limited to the file size incorrectly. * When precaching failed, the cache reference was not released. * The precaching started one page too late, causing bug #3835. * Reenabled precaching. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30515 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 79f73dbc Tue Dec 20 17:38:31 MST 2005 Axel Dörfler <axeld@pinc-software.de> * vm_page::offset is now called cache_offset and is now an uint32 instead of off_t; this saves 4 bytes per page. To compensate the loss of bytes, the offset is now stored in page size units, that's enough to address 2^44 or 16 TB (which is now the maximal supported file size!). * Renamed vm_page::ppn to physical_page_number. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15637 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 2b028fca Wed Nov 23 11:36:38 MST 2005 Axel Dörfler <axeld@pinc-software.de> Removed one TODO from the list: in case pages_io() fails, read_chunk_into_cache() will no longer panic, but free its allocated pages. I ran into this because BFS managed to create a file without data stream but with a length larger than 0... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15093 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 2b028fca Wed Nov 23 11:36:38 MST 2005 Axel Dörfler <axeld@pinc-software.de> Removed one TODO from the list: in case pages_io() fails, read_chunk_into_cache() will no longer panic, but free its allocated pages. I ran into this because BFS managed to create a file without data stream but with a length larger than 0... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15093 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 2d690920 Wed Apr 13 07:22:10 MDT 2005 Axel Dörfler <axeld@pinc-software.de> Renamed system/core to system/kernel. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12360 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff d5ad762913429ae34478222a0c87199be0709439 Thu Apr 30 09:53:41 MDT 2009 Axel Dörfler <axeld@pinc-software.de> Fixed several problems of the prefetching code: * Did claim to have reserved pages when calling vm_page_allocate_page(), but didn't have any (copy&paste bug). We cannot use it without reserved pages, as we need to call vm_page_allocate_page() with a cache locked. * No longer use low_resource_state() to determine whether to precache or not, but use the new vm_page_num_used_pages() instead. * Also don't (try to) precache when the cache already has more than 2/3 of its pages to safe some unnecessary work. * The size to precache was limited to the file size incorrectly. * When precaching failed, the cache reference was not released. * The precaching started one page too late, causing bug #3835. * Reenabled precaching. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30515 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 47c40a10a10dc615e078754503f2c19b9f98c38d 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 79f73dbc56ac58d027f33ad260c1eefbc1730935 Tue Dec 20 17:38:31 MST 2005 Axel Dörfler <axeld@pinc-software.de> * vm_page::offset is now called cache_offset and is now an uint32 instead of off_t; this saves 4 bytes per page. To compensate the loss of bytes, the offset is now stored in page size units, that's enough to address 2^44 or 16 TB (which is now the maximal supported file size!). * Renamed vm_page::ppn to physical_page_number. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15637 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 2b028fcaa02836669081839aa20fdf814081b1c0 Wed Nov 23 11:36:38 MST 2005 Axel Dörfler <axeld@pinc-software.de> Removed one TODO from the list: in case pages_io() fails, read_chunk_into_cache() will no longer panic, but free its allocated pages. I ran into this because BFS managed to create a file without data stream but with a length larger than 0... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15093 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 126 milliseconds