* added parsing for DQue, DQTi, DQSz, DQMi tags. This could be used to check if an application is actually installed.
* added parsing for PtcI (unknown use).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34981 a95241bf-73f2-0310-859d-f6bbb57e9c96
We can only access the page, if it is not busy. Fixes#5228.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34980 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Various smaller fixes.
* Used add_debugger_command_etc() and added more verbose usage message.
* Added option "-m" which iterates through all address spaces and finds out
which virtual pages are mapped to the page.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34979 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added Debug{First,Next}() methods to allow easy iteration through the
address spaces in kernel debugger commands.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34978 a95241bf-73f2-0310-859d-f6bbb57e9c96
device path + child partition name. When a "raw" device is unpublished the node
removal notification triggers the partition and child partitions to be
unpublished/removed. Since in that case the "raw" node is already unpublished
trying to resolve it in devfs_unpublish_partition() again to unpublish the child
partitions would fail, leaving the child partition nodes behind. When a new raw
device would then become available publishing its partitions would fail because
of these left behind nodes, causing bug #4587. Seeing that this code is more
compact and straight forward anyway I don't quite see why it was changed in the
first place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34967 a95241bf-73f2-0310-859d-f6bbb57e9c96
LockAllSourceCaches()) and moved it to the beginning of the file.
* Removed sMappingLock and adjusted the locking policy for mapping/unmapping
pages: Since holding the lock of the affected pages' caches is already
required, that does now protect the page's mappings, too. The area mappings
are protected by the translation map lock, which we always acquire anyway
when mapping, unmapping, or looking up mappings.
The change results in a -j8 Haiku image build speedup of almost 10%. The
total kernel time drops almost 30%.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34965 a95241bf-73f2-0310-859d-f6bbb57e9c96
Apparently (at least when running in VMware >=2) the boot loader can still
map the same physical page more than once -- in the ACPI or HPET code I
suppose -- which would lead to this situation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34954 a95241bf-73f2-0310-859d-f6bbb57e9c96
following function might otherwise not be shown correctly in ELF tools.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34952 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved hash computations out of the critical sections.
* Replaced the LRU entry queue by an array of entry "generations", each
containing a sparse array of entries of that generation. Whenever a
generation is full, we clear the oldest generation and continue with that
one. The main advantage of this algorithm is that entry cache's mutex could
be replaced by an r/w lock, that most of the time only has to be read
locked in Lookup(). This does dramatically decrease contention of that
lock.
The total -j8 Haiku image build speedup is marginal, but the kernel time
drops about 7% (now being smaller than the real time).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34950 a95241bf-73f2-0310-859d-f6bbb57e9c96
don't need it. That prevents us from ending up with the page being mapped
multiple times (under VMware at least) and thus fixes#5208.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34948 a95241bf-73f2-0310-859d-f6bbb57e9c96
allocate all pages the given range intersects with. When not page aligned
it could fail to allocate the last page.
* mmu_free():
- Adjusted semantics to be compatible with mmu_map_physical_memory().
- The validity check was broken, because page number and addresses were
mixed, and because KERNEL_BASE + kMaxKernelSize doesn't mark the end of
the allocated virtual ranges.
- The final check against sNextVirtualAddress was broken.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34947 a95241bf-73f2-0310-859d-f6bbb57e9c96
would yield double inversion of the caret position, causing #5006
* cleanup with respect to when the selection can be highlighted and/or the
caret can be shown/hidden
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34944 a95241bf-73f2-0310-859d-f6bbb57e9c96
protected by the global vnodes lock. The contention mostly moves to other
locks, though. The total -j8 Haiku image build time is only reduced
minimally.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34938 a95241bf-73f2-0310-859d-f6bbb57e9c96
contention about two orders of magnitude. Most of it seems to be taken over
by other locks, though. Yields only small improvements for the -j8 Haiku
image build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34937 a95241bf-73f2-0310-859d-f6bbb57e9c96
table. It is now inline and uses double-checked locking. This reduces the
contention on the lock to insignificant. Total -j8 Haiku image build speedup
is marginal, but the total kernel time drops 12%.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34934 a95241bf-73f2-0310-859d-f6bbb57e9c96
