Searched +hist:64 +hist:a9bd15 (Results 1 - 1 of 1) sorted by relevance

/haiku/src/system/kernel/cache/
H A Dfile_cache.cppdiff 0e88a887 Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel.

* Most of this is incorrect printf format strings. Changed all strings
causing errors to use the B_PRI* format string definitions, which
means the strings should be correct across all platforms.
* Some other fixes for errors, casts required, etc.
diff 64a9bd15 Tue Jan 26 14:30:50 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Optimized writing of zeroes to files. Instead of allocating a small buffer
on the fly, clearing and writing it each time, we now use an iovec with 32
identical entries pointing to a clear page that we prepare once at
initialization. This speeds up clear_image in low memory situations
dramatically.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35304 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 64a9bd15 Tue Jan 26 14:30:50 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Optimized writing of zeroes to files. Instead of allocating a small buffer
on the fly, clearing and writing it each time, we now use an iovec with 32
identical entries pointing to a clear page that we prepare once at
initialization. This speeds up clear_image in low memory situations
dramatically.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35304 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff cff6e9e4 Tue Jan 26 07:44:58 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * The system now holds back a small reserve of committable memory and pages. The
memory and page reservation functions have a new "priority" parameter that
indicates how deep the function may tap into that reserve. The currently
existing priority levels are "user", "system", and "VIP". The idea is that
user programs should never be able to cause a state that gets the kernel into
trouble due to heavy battling for memory. The "VIP" level (not really used
yet) is intended for allocations that are required to free memory eventually
(in the page writer). More levels are thinkable in the future, like "user real
time" or "user system server".
* Added "priority" parameters to several VMCache methods.
* Replaced the map_backing_store() "unmapAddressRange" parameter by a "flags"
parameter.
* Added area creation flag CREATE_AREA_PRIORITY_VIP and slab allocator flag
CACHE_PRIORITY_VIP indicating the importance of the request.
* Changed most code to pass the right priorities/flags.

These changes already significantly improve the behavior in low memory
situations. I've tested a bit with 64 MB (virtual) RAM and, while not
particularly fast and responsive, the system remains at least usable under high
memory pressure.
As a side effect the slab allocator can now be used as general memory allocator.
Not done by default yet, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35295 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 7b8683b2 Fri Oct 17 10:45:14 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> Updated write_to_cache() to use physical pages for I/O and the new
{memset,memcpy_to}_physical() functions.
Mapping lots of physical pages at once as done before was an actual
problem on systems with enough RAM, as the physical page mapper can map
only 64 chunks at a time. So multiple threads could play dining
philosophers, each getting only one of two chopsticks, waiting for
another one to be freed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28220 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 09149281 Thu Nov 08 02:30:58 MST 2007 Axel Dörfler <axeld@pinc-software.de> The file cache now completely bypasses the cache for writes equal or larger
than 64KB. Reads should probably get a similar logic, at least if memory is
tight.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22857 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a Wed Jun 13 10:42:46 MDT 2012 Alex Smith <alex@alex-smith.me.uk> First round of 64-bit safety fixes in the kernel.

* Most of this is incorrect printf format strings. Changed all strings
causing errors to use the B_PRI* format string definitions, which
means the strings should be correct across all platforms.
* Some other fixes for errors, casts required, etc.
diff 64a9bd15c856a4da7d017294df73dc4d46350e9b Tue Jan 26 14:30:50 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Optimized writing of zeroes to files. Instead of allocating a small buffer
on the fly, clearing and writing it each time, we now use an iovec with 32
identical entries pointing to a clear page that we prepare once at
initialization. This speeds up clear_image in low memory situations
dramatically.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35304 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff cff6e9e406132a76bfc20cb35ff5228dd0ba94d8 Tue Jan 26 07:44:58 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * The system now holds back a small reserve of committable memory and pages. The
memory and page reservation functions have a new "priority" parameter that
indicates how deep the function may tap into that reserve. The currently
existing priority levels are "user", "system", and "VIP". The idea is that
user programs should never be able to cause a state that gets the kernel into
trouble due to heavy battling for memory. The "VIP" level (not really used
yet) is intended for allocations that are required to free memory eventually
(in the page writer). More levels are thinkable in the future, like "user real
time" or "user system server".
* Added "priority" parameters to several VMCache methods.
* Replaced the map_backing_store() "unmapAddressRange" parameter by a "flags"
parameter.
* Added area creation flag CREATE_AREA_PRIORITY_VIP and slab allocator flag
CACHE_PRIORITY_VIP indicating the importance of the request.
* Changed most code to pass the right priorities/flags.

These changes already significantly improve the behavior in low memory
situations. I've tested a bit with 64 MB (virtual) RAM and, while not
particularly fast and responsive, the system remains at least usable under high
memory pressure.
As a side effect the slab allocator can now be used as general memory allocator.
Not done by default yet, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35295 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 7b8683b2524b1f17bbeb53eddbe7eeda48898df5 Fri Oct 17 10:45:14 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> Updated write_to_cache() to use physical pages for I/O and the new
{memset,memcpy_to}_physical() functions.
Mapping lots of physical pages at once as done before was an actual
problem on systems with enough RAM, as the physical page mapper can map
only 64 chunks at a time. So multiple threads could play dining
philosophers, each getting only one of two chopsticks, waiting for
another one to be freed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28220 a95241bf-73f2-0310-859d-f6bbb57e9c96

Completed in 41 milliseconds