Searched +hist:20 +hist:b232e9 (Results 1 - 2 of 2) sorted by relevance

/haiku/src/system/kernel/cache/
H A Dfile_cache.cppdiff 425ac1b6 Tue Jun 20 16:57:22 MDT 2023 Alexander von Gluck IV <kallisti5@unixzen.com> refactor: Swap %Ld for %lld in all format usages

* %Ld is an undocumented alias for %lld in glibc.
* muslc doesn't implement it for this reason.
* While we will likely never drop %Ld support,
lets clean house and set a better example.

Change-Id: Id46dad3104abae483e80cc5c05d1464d3ecd8030
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6636
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
diff b344d252 Sat Jun 20 15:21:56 MDT 2020 Augustin Cavalier <waddlesplash@gmail.com> kernel/file_cache: Move write_zeros_... call out of else.

Style only, no functional change. Requested by axeld.
diff 435c43f5 Wed Jun 02 12:42:20 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Introduced type generic_io_vec, which is similar to iovec, but uses types
that are wide enough for both virtual and physical addresses.
* DMABuffer, IORequest, IOScheduler,... and code using them: Use
generic_io_vec and generic_{addr,size}_t where necessary.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36997 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff bd7645a1 Sat Feb 20 08:57:44 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Made vm_page::state private and added accessor methods.
* Added kernel tracing for page state transitions.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35538 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 9824ded0 Sat Feb 20 03:51:53 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> cache_io(): Also requeue the last touched page to keep things roughly LRU
sorted.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35530 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8a26f35a Mon Apr 20 02:02:51 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Sequential write accesses were never detected, due to an incorrect check.
* 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
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 0d871d3c Mon Oct 08 20:04:36 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * satisfy_cache_io() was using the wrong value to compute the number of
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
diff 20b232e9 Sun Oct 07 07:32:13 MDT 2007 Axel Dörfler <axeld@pinc-software.de> Actually forgot this nail: the file cache will now reserve the pages it will
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
diff 20b232e9 Sun Oct 07 07:32:13 MDT 2007 Axel Dörfler <axeld@pinc-software.de> Actually forgot this nail: the file cache will now reserve the pages it will
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
/haiku/src/system/kernel/vm/
H A Dvm_page.cppdiff be1cc9c8 Sat Jun 20 15:07:03 MDT 2020 Augustin Cavalier <waddlesplash@gmail.com> kernel/vm: Make the page_scrubber wait on a condition.

On an idle system with 1GB RAM and the 100ms timeout, it takes multiple
minutes for all the pages in the system to get cleared after boot, but once
they do, the page scrubber will then remain idle for seconds to even
minutes at a time, so this is clearly worth it.

The "free pages condition" was unused before this commit, so I have
repurposed it (and unpublished it.)

Change-Id: I7034677a1e51c97c2baf11b772db3a31c0e1adfa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1699
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff d02aaee1 Sun Dec 15 20:53:46 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Add more memory info in system_info

system_info now contains all information previously available only
through __get_system_info_etc(B_MEMORY_INFO, ...).
diff c8dd9f77 Tue Oct 29 20:58:36 MDT 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel: Add thread_unblock() and use it where possible
diff 4be4fc6b Fri Jun 15 09:04:20 MDT 2012 Alex Smith <alex@alex-smith.me.uk> More 64-bit compilation/safety fixes.
diff 435c43f5 Wed Jun 02 12:42:20 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Introduced type generic_io_vec, which is similar to iovec, but uses types
that are wide enough for both virtual and physical addresses.
* DMABuffer, IORequest, IOScheduler,... and code using them: Use
generic_io_vec and generic_{addr,size}_t where necessary.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36997 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 24244d3c Sat Feb 20 10:24:14 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> idle_scan_active_pages(): vm_page_requeue() requires the caller to mark the
page accessed for the access debugging feature.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35542 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 4a1f6683 Sat Feb 20 10:17:22 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Also print the page for the page related asserts.
* Used vm_page::IsMapped() to simplify things.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35541 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 3e5343f2 Sat Feb 20 09:45:44 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> free_cached_page(): Removed incorrect asserts. The same ones appear a few
lines later anyway, after the cache has been locked and it has been verified
that the page is still a candidate. Fixes #5432.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35539 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff bd7645a1 Sat Feb 20 08:57:44 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * Made vm_page::state private and added accessor methods.
* Added kernel tracing for page state transitions.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35538 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff bcc2c157 Wed Jan 13 20:26:12 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Refactored vm_translation_map:
* Pulled the physical page mapping functions out of vm_translation_map into
a new interface VMPhysicalPageMapper.
* Renamed vm_translation_map to VMTranslationMap and made it a proper C++
class. The functions in the operations vector have become methods.
* Added class GenericVMPhysicalPageMapper implementing VMPhysicalPageMapper
as far as possible (without actually writing new code).
* Adjusted the x86 and the PPC specifics accordingly (untested for the
latter). For the other architectures the build is, I'm afraid, seriously
broken.

The next steps will modify and extend the VMTranslationMap interface, so that
it will be possible to fix the bugs in vm_unmap_page[s]() and employ
architecture specific optimizations.


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

Completed in 198 milliseconds