Commit Graph

10 Commits

Author SHA1 Message Date
Ingo Weinhold
47c40a10a1 * 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
2008-10-20 00:06:09 +00:00
Axel Dörfler
0e18334057 * Mapping a page might actually need memory - since we usually have locks that
interfere with the page thief, we always need to have reserved a page for
  this upfront. I introduced a function to the vm_translation_map layer that
  estimates how much pages a mapping might need at maximum. All functions that
  map a page now call this and reserve the needed pages upfront.
  It might not be a nice solution, but it works.
* The page thief could run into a panic when trying to call vm_cache_release_ref()
  on a non-existing (NULL) cache.
* Also, it will now ignore wired active pages.
* There is still a race condition between the page writer and the vnode
  destruction - writing a page back needs a valid vnode, but that might just
  have been deleted.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22455 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-10-06 11:18:21 +00:00
Axel Dörfler
6e601ee88f get_memory_map() now panics (and fails) in case it was called on unmapped memory as
suggested by Ingo; before it would just fill the physical pages with NULL pointers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20364 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-03-11 13:27:42 +00:00
Axel Dörfler
573c4336a3 Implemented quite a hack to solve the lockless get_memory_map() problem (bug #349):
when called with interrupts turned off, get_memory_map() will now call the new
vm_translation_map_ops::query_interrupt() call.
Under PPC, this is trivial (at least right now), but on x86 we need to make sure
we have access to the page table entry, ie. we need to create an area that points
to its own page table entry, so that we can map in the page table entry containing
the address we're looking for. It's not really nice, feel free to come up with
a cleaner solution :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17280 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-04-30 17:45:33 +00:00
Axel Dörfler
74b043d98d Removed execute property that was set accidently (since CVS days).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11896 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-03-18 01:50:45 +00:00
Axel Dörfler
67a53f72af - the arch_vm_translation_map.c exported functions now have the arch_ prefix
- the above file now also exports a function to finally complete the kernel's
  address space translation map after semaphores became available (was just
  not done before)
- renamed some functions, especially the *_init2() functions are now called
  like *_init_post_area() to indicate they are called after the area functionality
  became available
- removed the _struct suffix from certain structures
- fixed some return types
- added prototype for vm_free_unused_boot_loader_range() to be called by
  arch code.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9423 a95241bf-73f2-0310-859d-f6bbb57e9c96
2004-10-19 23:19:10 +00:00
Axel Dörfler
746bb367c0 Replaced "addr" with "addr_t", improved other types.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8028 a95241bf-73f2-0310-859d-f6bbb57e9c96
2004-06-17 13:22:05 +00:00
Axel Dörfler
e45975b879 Definitions were doubled in vm_translation_map.h and arch/vm_translation_map.h.
The former now only contains the structure definitions, while the other one
contains the arch-specific function prototypes (which do not have the arch_
prefix).
Added a ToDo comment to remember cleaning this up one day.
Made all headers C++ safe, simplified where possible.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@5197 a95241bf-73f2-0310-859d-f6bbb57e9c96
2003-10-28 21:10:00 +00:00
Axel Dörfler
564cba312e Some header work: removed unnecessary dependencies to stage2.h, fixed
some broken C++ export definitions, added missing licenses etc.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3152 a95241bf-73f2-0310-859d-f6bbb57e9c96
2003-05-03 16:03:26 +00:00
ejakowatz
52a3801208 It is accomplished ...
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10 a95241bf-73f2-0310-859d-f6bbb57e9c96
2002-07-09 12:24:59 +00:00