This is relatively harmless in all cases except where the lower 32 bits
are all zeroes, as in that case we would never get a timer interrupt.
In all other cases we would just time out too soon, and the timer
interrupt handler would reschedule.
We need to add clock divisor selection to this module so that we can
be sure that at least reasonably-sized timeouts (a few seconds, e.g.)
will not overflow 32 bits, though.
Change-Id: I62c829aa740bbd611aab788854d722cfa659a0d8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9001
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It is on VMware at least, and is faster and more accurate than measuring.
Change-Id: I42cd16869ca8531bb9710b148609d8218ff870e8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9000
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We use the TSC to measure the APIC frequency, but the TSC frequency
is only fully initialized in the kernel (where it's read from CPUID
on recent hardware).
Furthermore, on some more recent systems, it seems there may only be
X2APIC and no MMIO APIC timer at all, and the bootloader does not
handle that case.
The method in the kernel uses spin() instead of a fixed instruction
count as well as system_time_nsecs() and a double for (hopefully)
more accurate calibration.
At least on VMware, this method seems more accurate: the APIC frequency
read from the hypervisor CPUID leaf is 66,000,000; the old method in
in the bootloader yielded values like "65,801,075" and "65,106,382",
while the new one yields values like "65,963,920" and "65,962,580"
(those pairs of values are from two consecutive boots.)
The difference was sometimes similar (but smaller as a percentage) in
QEMU with software emulation: e.g. "993,218,085" vs. "992,965,761". But
sometimes it wasn't: e.g "991,619,585" vs. "993,689,669". (QEMU in
software mode doesn't report a frequency via hypervisor CPUID leaf.)
Change-Id: I4fb8535d1d984f13867e2f84e7dfad1ceed42c13
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8999
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* If WAITING is not set, we don't need to call unblock().
* When exiting wait() and there are no more waiters, zero out
the lock entirely.
Helps with #18216 a bit.
This way we are less likely to encounter "Failed to acquire ... for
a long time", especially when onscreen debug output is enabled.
In the pending repeats checker, we wait at most 100ms to acquire the lock,
since this is run on the "kernel daemon" thread which we don't want
to block for too long.
In the device driver architecture documentation there is a
TODO for adding an image representation of the device node
tree in Haiku.
This patch adds a .svg image for the same, removing the TODO
line.
Change-Id: If5d1e3ee5abe7d6e84245c837b5cb2f1f0cb670a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8983
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: nephele nephele <nep-git@packageloss.eu>
Instead of unconditionally calling _DeriveLabel() and Invalidate()
every time (both expensive operations), use a bool to track whether
we've already invalidated, and derive the label in Draw() if it
was set.
Significantly decreases the invalidations done on full-list rebuilds.
* _UpdateThumbFrame() calls Invalidate() already, don't call it again
in SetRange unnecessarily.
* If the new and old thumb frames are the same, skip invalidation.
Saves a lot of Invalidate() calls in HaikuDepot on building the
"all packages" list especially.
* package->Name() is always lowercase, don't bother using lowercase
operations on it.
* Use IFindFirst rather than transforming the string; this uses
strcasestr internally which operates per-character.
Loosely based on a patch by oco in #19421.
when a non-null value is found, up to PTHREAD_DESTRUCTOR_ITERATIONS (4).
* fixes LLVM unit test SanitizerCommon.PthreadDestructorIterations.
Change-Id: I1f9f4d3e8723261326e6e22b0f0d23907dccb59f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8979
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This case happens now and again, including a few dozen times in the
bootloader, hundreds of times on boot, and thousands of times
when running "git status" on larger repositories.
It reduces block_cache contention in "git status buildtools" specifically
from ~10m1s wait time to ~9m13s, and overall time from ~36.2s to ~33.5s
(in a 4-core VM.)
This only matters when the area exactly at the address is a reserved one,
which probably does not happen so often (this case is only used from
AreaRangeIterator at the moment.)
It was disabled because hoard2 triggered it far too often.
But now that we're using OpenBSD malloc with different glue,
this isn't an issue anymore.
Closes #18451.
Change-Id: I9a3b1190edbbe0ae3cedfe4df2993441d1f2d629
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8975
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
jam HaikuDepot with nothing to do, best of many runs:
hoard2
real 0m3.519s
user 0m3.348s
sys 0m0.159s
openbsd
real 0m3.481s
user 0m3.327s
sys 0m0.147s
time printf "continue\nsave-report\nquit\nk\n" | Debugger -c Debugger -s 1000
hoard2
real 0m2.295s
user 0m2.505s
sys 0m0.128s
openbsd
real 0m2.896s
user 0m2.809s
sys 0m0.579s
The performance difference in Debugger is due to OpenBSD malloc
actually decommitting memory. If we disable decommit, then
OpenBSD malloc is faster than hoard2 in this case also.
In some particular cases this is a huge speedup. For example, the link
of the "lto-dump" program in GCC seems to hit a pathological case in
hoard2 and our glue code for it; with hoard2 it takes around 23 seconds,
but with this allocator it takes only 2 seconds (!). Overall the
performance difference is much more modest, though.
Overall, system memory usage seems to be up about ~5% (318 MB -> 334 MB
just after boot), and that seems to mostly be due to the allocator
filling its initial caches faster when allocations occur, rather than
lazily allocating.
Change-Id: I071d8f76fbbfa11547bd6da6bf649d111414e780
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8974
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* PagesAllocator: A process-global caching strategy for the allocator.
It deals with allocating virtual addresses and memory, and gives us
back some of the performance that's lost by having an actual
decommitment strategy (which the hoard2 glue code doesn't.)
It uses two SplayTrees to manage free lists, and resizes areas
on allocate if they aren't next to a free chunk (which saves a lot of
time for large reallocations.)
There's still room for improvement here, see inline TODOs. But overall
we get pretty good performance with it.
* Add a TLS slot for the allocator glue to use. Right now it just puts
integers in there (since thread IDs are not evenly distributed),
but we could put a data structure pointer in there as well, potentially.
Change-Id: I56ddb0b022a468dc04275075ed7e174b339c8ca4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8335
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Exactly as-is. Modifications and integration will come in
the next commit.
Change-Id: I685483992d7f593fc46154ddea85a91798044faa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8973
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If we succeed in sending the message on the first try, then we don't
need to allocate anything at all.
This two allocations and a memcpy in the fast path (which is
hit the vast majority of the time, it appears.)
Some methods already did, but used a very large size of 16KB.
Reduce that to 4KB, do it in more places, and use BStackOrHeapArray
where possible.
Change-Id: Ia2d64582e76da6c1850e502107c07cb10bcd8226
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8969
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Rather than allocating a block in the constructor, just wait to
do it until we actually need to add items to the list. This saves
over 200,000 allocations when running "pkgman search" alone.
Change-Id: Ia6a21b963efded2bb4973edc2ba22ff026e01737
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8630
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Handle resizing areas past a reservation, fixing a longstanding TODO.
(The kernel address space implemenation still has the same TODO however.)
* Handle resizing areas past or inside more than one reservation at once.
* When an area shrinks, and it's touching/inside a reservation, expand
the reservation downwards at least to its original size.
Add tests for all these behaviors (they're passing.)
This is now obsolete as the preferred merge strategy is just to
copy the whole directories and then reinstate the __HAIKU__
directives, same as for the FreeBSD network drivers and other
such code.
This is used by some Tracker add-ons including TrackRunner and TrackGit.
Fixes #19386
Change-Id: I329eb9f1f8b2abf2872593d8f4417fa82de0b521
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8911
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Otherwise we'll try to write to some random register at or past the end.
Adjust the bitmasks: rename XHCI_LEGCTLSTS_DISABLE_SMI to RESERVED_BITS
and define it in hex. Also add the "read-only" bits as a separate
declaration, and don't touch those either; then remove the setting
of the "events SMI" bits.
We always did under EFI but not under BIOS. Now, the BIOS loader
reports the root pointer as well, so we don't need to find it again.
Change-Id: Ie83adb53f098d44f2688a1a327c084f94afa2673
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8941
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is necessary when the TEXT section is split.
At this point it may make more sense for libroot to register such
atexit hooks with runtime_loader rather than allocating them itself,
in line with the above comment's suggestion, but that can be investigated
some other time.
Previously this would simply tint the passed in background color.
After hrev58595 this was changed to pass the proper Foreground color instead.
The codepath to disable/enable the color was missed in an oversight,
this puts back the original tint color for the foreground aswell.
Fixes: #19406
Change-Id: I6f75d24316e8ca3ecdb78f11fc8dede88f082780
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8958
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
... related to Pose and TextWidget not exactly matching.
Change-Id: Ic9c3f2ecc9a9dc4af4c200bc5a16b9f46d72f9b1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8954
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
