Searched +hist:9 +hist:edc2b52 (Results 1 - 1 of 1) sorted by relevance
/haiku/src/system/kernel/cache/ | ||
H A D | file_cache.cpp | diff 9c5c5990 Mon Sep 15 15:18:25 MDT 2014 Paweł Dziepak <pdziepak@quarnos.org> kernel: pagecache: provided buffers are not always in user memory Source or destination buffers passed to pagecache functions may belong to kernel memory (e.g. when the caller is packagefs). Because of that we should tell vm_memcpy_{from, to}_physical() truth, not assume that all buffers are in user memory. That's important because user memory page fault handlers cannot be nested and these functions may be used while handling a page fault. With high probability fixes #11246. Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org> diff eb2bd0e8 Mon Apr 27 12:16:58 MDT 2009 Stephan Aßmus <superstippi@gmx.de> axeld: * Implemented a way to do asynchronous pre-fetching when mapping files. * There are slight code duplications in some places that could benefit from cleaning up, but nothing too bad. * Implementing smarter ways to trigger prefetching and more analysis of the situations in the kernel would be nice. Currently up to 10 MB of every mapped file are pre-fetched without further analysis. * The speed improvement is nice for certain operations. On our test system (real hardware), Firefox took 9 seconds from being launched to display a window. Now it takes 5 seconds. Both measurements right after booting. The same system took 35 seconds from launching Haiku in the GRUB menu to displaying the Tracker desktop background image. Now it takes 27 seconds. * We didn't have the chance to check out the effects of this on the CD boot, but potentially, they could speed it up a lot. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30465 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9a0fc9a8 Thu Jul 31 13:23:17 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> In cache_io(): Don't keep the cache locked while doing a user_{memcpy,memset}(), since that can cause a page fault, which needs pages and might try to steal some from our cache. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26700 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9e1ea0e7 Sat Jun 28 18:13:03 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> Don't leak the buffer allocated at the beginning of the function. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26161 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9ff70e74 Mon Nov 26 06:38:32 MST 2007 Axel Dörfler <axeld@pinc-software.de> read_from_file() and write_to_file() did not take the pageOffset into account. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22998 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9edc2b52 Thu Nov 08 07:44:13 MST 2007 Axel Dörfler <axeld@pinc-software.de> The reserved pages computation used the same broken logic as read_into_cache() and write_to_cache() before, IOW the cache could reserve too few pages. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22859 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9edc2b52 Thu Nov 08 07:44:13 MST 2007 Axel Dörfler <axeld@pinc-software.de> The reserved pages computation used the same broken logic as read_into_cache() and write_to_cache() before, IOW the cache could reserve too few pages. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22859 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9c5c5990414f9570d5271328ce67252d50dfe8a2 Mon Sep 15 15:18:25 MDT 2014 Paweł Dziepak <pdziepak@quarnos.org> kernel: pagecache: provided buffers are not always in user memory Source or destination buffers passed to pagecache functions may belong to kernel memory (e.g. when the caller is packagefs). Because of that we should tell vm_memcpy_{from, to}_physical() truth, not assume that all buffers are in user memory. That's important because user memory page fault handlers cannot be nested and these functions may be used while handling a page fault. With high probability fixes #11246. Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org> diff eb2bd0e8e3689998717f91d8b9023296e3f32e78 Mon Apr 27 12:16:58 MDT 2009 Stephan Aßmus <superstippi@gmx.de> axeld: * Implemented a way to do asynchronous pre-fetching when mapping files. * There are slight code duplications in some places that could benefit from cleaning up, but nothing too bad. * Implementing smarter ways to trigger prefetching and more analysis of the situations in the kernel would be nice. Currently up to 10 MB of every mapped file are pre-fetched without further analysis. * The speed improvement is nice for certain operations. On our test system (real hardware), Firefox took 9 seconds from being launched to display a window. Now it takes 5 seconds. Both measurements right after booting. The same system took 35 seconds from launching Haiku in the GRUB menu to displaying the Tracker desktop background image. Now it takes 27 seconds. * We didn't have the chance to check out the effects of this on the CD boot, but potentially, they could speed it up a lot. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30465 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 9a0fc9a874cdc1b1f692630c7b13a519a184d35b Thu Jul 31 13:23:17 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> In cache_io(): Don't keep the cache locked while doing a user_{memcpy,memset}(), since that can cause a page fault, which needs pages and might try to steal some from our cache. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26700 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 98 milliseconds