Searched +hist:9 +hist:edc2b52 (Results 1 - 1 of 1) sorted by relevance

/haiku/src/system/kernel/cache/
H A Dfile_cache.cppdiff 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