it anymore after having called vfs_asynchronous_read_pages().
* Now, Prepare() does all the preparation work, and ReadAsync() does the actual
work - this must be called without having the cache locked. This also fixes
another bug where the callback would be deleted twice in case the I/O request
failed.
* This fixes bug #3847.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30632 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
* vfs_read_pages_async() must not be called with locked cache,
since it cannot be guaranteed that the operation will be
performed asynchronously. (The ISO9660 FS for example does not
implement the new IO hooks... yet.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30476 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
* 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
IORequest.{h,cpp}.
* Introduced public <io_requests.h> header. Currently it only declares the
single function BFS uses.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29446 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
{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
PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag
PHYSICAL_PAGE_DONT_WAIT.
* Pass the flags through to the chunk mapper callback.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added file_map_set_mode() function that you can use to keep a whole file
cached. This is needed for the swap file support: FILE_MAP_CACHE_ALL will
not only precache all file_io_vecs when called, but it will also cause all
file_map_translate() calls to fail that would require further caching (ie.
if the file size had changed).
* Updated the fs_shell file map code to the latest one (with several bug fixes).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26785 a95241bf-73f2-0310-859d-f6bbb57e9c96
actual caching in the file cache, i.e. all reads and writes go directly
to the underlying device. The implementation is not quite complete,
since the VM can still add pages to the cache when the file is mmap()ed,
which can lead to inconsistencies.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26779 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
partially (e.g. due to hitting the end of file). The respective
classes have grown new methods and attributes to deal with that. The
"finished" callbacks have got additional parameters to indicate
whether the transfer was only partial and how much has been
transferred. Other callbacks and functions have a size_t* in/out
parameter instead of a simple size_t, now.
* vfs_{read,write}_pages() do now use the I/O request framework instead
of the underlying FS's {read,write}_pages() hooks (those should be
unused now). Furthermore they've got an additional "flags" parameter,
which is passed to IORequest::Init(), i.e. it allows to specify that
the given vecs refer to physical addresses.
* The file cache's read_into_cache() reads directly into physical
pages, now.
* Fixed bug in DoIO::IO(): The offset was not adjusted, so that all
pages were incorrectly transferred from/to the same location.
* Fixed broken subrequest scheduling loop head in
do_iterative_fd_io_iterate().
* Adjusted the test driver and implemented its io() hook. Using this
driver I/O requests are passed all the way from the VFS/VM to the
driver and through the I/O scheduler. It even seems to work. :-)
* Added missing const to the iovec* parameter of the IORequest::Init()
methods.
* Disabled some debug output by default. Added new optional debug
output.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26692 a95241bf-73f2-0310-859d-f6bbb57e9c96
fs_vnode_ops::write_pages() to be called with fsReenter = true. Since
this is no longer the case, the argument has become superfluous. For
read_pages() it always was. Removed the argument from the functions
and all functions that propagated it.
* Some whitespace at the end of lines was removed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26579 a95241bf-73f2-0310-859d-f6bbb57e9c96
introduces the following relevant changes:
* VMCache:
- Renamed vm_cache to VMCache, merged it with vm_store and made it a
C++ class with virtual methods (replacing the store operations).
Turned the different store implementations into subclasses.
- Introduced MergeStore() callback, changed semantics of Commit().
- Changed locking and referencing semantics. A reference can only be
acquired/released with the cache locked. An unreferenced cache is
deleted and a mergeable cache merged when it is unlocked. This
removes the "busy" state of a cache and simplifies the page fault
code.
* Added VMAnonymousCache, which will implement swap support (work by
Zhao Shuai). It is not integrated and used yet, though.
* Enabled the mutex/recursive lock holder asserts.
* Fixed DoublyLinkedList::Swap().
* Generalized the low memory handler to a low resource handler. And made
semaphores and reserved memory handled resources. Made
vm_try_resource_memory() optionally wait (with timeout), and used that
feature to reserve memory for areas.
...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26572 a95241bf-73f2-0310-859d-f6bbb57e9c96
using it.
* IOW cache_prefetch_vnode() should work again now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26468 a95241bf-73f2-0310-859d-f6bbb57e9c96
per cache.
* Changed the strategy vm_cache_acquire_page_cache_ref() uses to ensure
that the cache isn't deleted while trying to get a reference. Instead
of the global cache pages hash table lock, it holds the global cache
list lock now. We acquire + release this lock in delete_cache() after
removing all pages and just before deleting the object.
* Some small optimizations using the property that the cache's pages are
ordered, now (vm_cache_resize(), vm_page_write_modified_page_range(),
vm_page_schedule_write_page_range()).
* Replaced some code counting a cache's pages by simply using
vm_cache::page_count.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26160 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Trivial adjustments of code using mutexes. Mostly removing the
mutex_init() return value check.
* Added mutex_lock_threads_locked(), which is called with the threads
spinlock being held. The spinlock is released while waiting, of
course. This function is useful in cases where the existence of the
mutex object is ensured by holding the threads spinlock.
* Changed the two instances in the VFS code where an IO context of
another team needs to be locked to use mutex_lock_threads_locked().
Before it required a semaphore-based mutex implementation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25283 a95241bf-73f2-0310-859d-f6bbb57e9c96
respective Private* base class.
* Changed sigwait() and sigsuspend() to use thread_block() instead of a
condition variable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25100 a95241bf-73f2-0310-859d-f6bbb57e9c96
file system to not fill newly created space with zeros.
BFile::SetSize() now uses this, while [f]truncate() does not. This
is only a temporary work-around until BFS supports sparse files.
* Apps that want to reserve space to fill up later should use
BFile::SetSize() for now, as this will be a lot faster than
[f]truncate().
* cache_io() and the functions below now use a special mode when you
pass in a NULL buffer: for read access, the cache is only populated
(useful for prefetching), for write access, the file is filled with
zeros.
* Implemented BFS's Inode::FillGapWithZeros() using this method now.
* Removed extraneous white space.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24555 a95241bf-73f2-0310-859d-f6bbb57e9c96
that can be used by file systems.
* Changed the way the file cache works: instead of reading/writing to the
underlying device directly, it can now be used for any data source, ie.
also network file systems.
* As a result, the former pages_io() moved to the VFS layer, and can now be
called by a file system via {read|write}_file_io_vec_pages() (naming
suggestions are always welcomed :-)). It now gets an FD, and uses that to
communicate with the device (via its fs_{read|write}_pages() hooks).
* The file_cache_{read|write}() functions must now be called without holding
an I/O relevant file system lock. That allows the file cache to prepare the
pages without colliding with the page writer, IOW the "mayBlock" flag can
go into the attic again (yay!).
* This also results in a much better performance when the system does I/O and
is low on memory, as the page writer can now finally write back some pages,
and that even without maxing out the CPU :)
* The API changes put slightly more burden on the fs_{read|write}_pages()
hooks, but in combination with the file_map it's still pretty straight
forward. It just will have to dispatch the call to the underlying device
directly, usually it will just call its fs_{read|write}_pages() hooks
via the above mentioned calls.
* Ported BFS and FAT to the new API, the latter has not been tested, though.
* Also ported the API changes to the fs_shell. I also completely removed its
file cache level page handling - the downside is that device access is no
longer cached (ie. depends on the host OS now), the upside is that the code
is greatly simplified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22886 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
needed pages correctly, and would also not read/write enough in case the
offset didn't start at 0 resulting in undetected short reads/writes. It's
amazing how many bugs can be hidden in a few lines of code.
* Fixed a bug that might have been the cause for bug #1601: when the last part
of the write did not end on a page boundary, the last page had to be read
first, but that was done from the wrong offset. Also, if only parts of that
page could be read (because the file size didn't span over the whole page)
the remaining parts needed to be cleared.
* The cache_funcs were always called with the same value for numBytes and
bufferSize so I've eliminated the former.
* Large reads now also bypass the cache in case of low memory, large writes now
also only bypass the cache in that case, following Ingo's suggestion.
* Fixed compilation with debugging turned on.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22858 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
sequential access.
* This is now used to let the cache free some pages (or schedule them to be
written back) before vm_reserve_pages() is called, but only if that cache
is not mapped, and there is a memory shortage.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22731 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
busy vnodes.
* dir_create_entry_ref() used get_vnode() incorrectly (and could therefore
potentially prevent a file system from doing proper locking when called
from the kernel).
* The vnode_store now uses this for its acquire_unreferenced_ref()
implementation (and therefore for the page writer).
* read_into_cache() and write_to_cache() were still marked inline.
* The system will now wait 10 secs for a busy vnode before returning an error.
* It will also no longer panic in that case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22485 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
twice into the same cache: cache_io() called read_into_cache() (or
write_to_cache()), and that broke down the request into smaller parts.
It then called read_chunk_into_cache() (or write_chunk_to_cache() resp.)
to actually allocate pages and fulfill the request.
However, it needed to unlock the cache for each chunk, and in the mean
time someone else could insert pages into the remaining chunks.
* Now, cache_io() already takes care of chunking the data which makes this
approach safe, and also simplified the code a bit - read_into_cache()/
write_to_cache() are gone now. I've renamed read_chunk_into_cache() to
read_into_cache() (same for the write function).
* Also got rid of that goto in that function while I was on it.
* Disabled cache_prefetch_vnode() for now (it's similar to cache_io(), but
since it's currently not used [since no cache module is installed yet],
I didn't want to go through updating it now, too).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22465 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the page writer don't allow to block, while all other writers do. This fixes
bug #1509. The reason the page writer needs this is because it marks several
pages from different caches as busy.
* Fixed a warning about ASSERT being defined already in BFS, since
util/DoublyLinkedList.h now includes debug.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22434 a95241bf-73f2-0310-859d-f6bbb57e9c96
is tracked while the page scanner runs much slower. Now, we just set it to a
fixed positive, so that they can easily age in case they are actually unused.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22320 a95241bf-73f2-0310-859d-f6bbb57e9c96
are locked, there is now a vm_page_reserve_pages() call to ensure upfront that
there is a page for me when I need it, and may have locked some caches.
* The vm_soft_fault() routine now makes use of that feature.
* vm_page_allocate_page() now resets the vm_page::usage_count, so that the file
cache does not need to do this in read_chunk_into_cache() and
write_chunk_to_cache().
* In cache_io() however, it need to update the usage_count - and it does that
now. Since non-mapped caches don't have mappings, the page scanner will punish
the cache pages stronger than other pages which is accidently just what we
want.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22319 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed the vm_cache/vm_store ref_count duality that besides being a bit ugly
also created the page dameon cache retrieval problem: now, only areas (and
cache consumers) retrieve a reference to the store (and therefore, the vnode).
The page daemon doesn't need to care about this at all anymore, and the pseudo
references of the vm_cache could be removed again.
* Rearranged deletion of vnodes such that its ID can be reused directly after
fs_remove_vnode() has been called.
* vm_page_allocate_page() no longer panics when it runs out of pages, but just
waits for new pages to become available using the new sFreeCondition condition
variable - to make sure this happens in an acceptable time frame, it'll
trigger a run of the low memory handlers.
* Implemented a page_thief() that steals inactive pages from caches and puts
them into the free queue. It runs as a low memory handler.
* The file cache now sets the usage count on the pages it inserts into the
cache (needs some rework though, cache_io() doesn't do it yet).
* Instead of panicking, the kernel will currently dead lock in low memory
situations, since BFS does a bit too much in bfs_release_vnode().
* Some minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22315 a95241bf-73f2-0310-859d-f6bbb57e9c96
correct values (resolving a TODO); however, the latter doesn't do anything
with those yet.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22154 a95241bf-73f2-0310-859d-f6bbb57e9c96
since fault_find_page() does no longer insert a dummy page into a cache
that has a store from which it can read the page.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21887 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed a few instances where the page state was set busy directly after
allocating it. This is a no-op, since a page is always busy after
allocation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21875 a95241bf-73f2-0310-859d-f6bbb57e9c96
removed in several cases.
* vfs_get_vnode_cache() now always gives out a reference to the cache it
returns; if it needs to allocate a new one, the vnode owns one reference,
and the caller another.
* therefore, file_cache_create() now owns a reference to its vm_cache_ref, and
frees it in file_cache_delete().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21533 a95241bf-73f2-0310-859d-f6bbb57e9c96
small to hold the information for the requested I/O size.
* get_file_map() returned B_BUFFER_OVERFLOW already in case the array
was exactly as large as needed.
* read_chunk_into_cache() and write_chunk_to_cache() will no longer
override their local "size" variable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20509 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a few comments.
* Simplified the nested while loops by dropping the special handling for the
first iovec and restructuring the innermost loop. This also rules out
the possibility of a zero-length temporary vec. IMHO the readability
has improved quite a bit (YMMV :-). Hopefully without introducing new
bugs; please review!
* Corrected computation of totalSize in case less than size has been
read/written.
* Also set *_numBytes in case all fileVecs have been processed. Only
relevant in case the request extends beyond the end of file.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20483 a95241bf-73f2-0310-859d-f6bbb57e9c96
filling them which could have written over the stack, and their iovec length
was set for the wrong iovec, potentially clobbering any memory.
* The first tempVec was usually empty, anyway, as the wrong iovec was chosen
to start from (usually one too early).
* The tempVec loop is now repeated until the whole fileVec is completed.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20476 a95241bf-73f2-0310-859d-f6bbb57e9c96
Axel Dörfler