It was disabled when adding the hypervisor CPUID leaf reading to
the bootloader, but that's not really necessary. This way, if
a hypervisor does not provide that CPUID leaf but does provide
the value in the standard CPUID or MSR, we will still read it
correctly anyway.
This reverts commit 0caf23319cb4e9f9c8a2ecd30e133e98a1d2b989.
This change is not safe because changing MAIR may invalidate
early mappings. It's also not clear if it's needed, as e.g.
FreeBSD does not use Device GRE mappings.
Change-Id: I95a904ee928281d44989ce707ed1ac59985a308d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8268
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Milek7 Milek7 <me@milek7.pl>
* Use fInitialLevel throughout
* Fix a mix-up of platform-independent and platform-dependent flags.
* Use break-before-make in Protect()
Change-Id: Idfd69727ca5c438fe89df830d5e61780c3fb6a36
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8258
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Milek7 Milek7 <me@milek7.pl>
EntryCacheEntry was padded out to 40 bytes, so this doesn't increase
its size (on 64-bit platforms).
Also increase entriesSize to actually be a power of 2.
This saves us a string comparison when the hashes don't match.
It saved around ~1400 such string comparisons during a boot, and then
rebuilding HaikuDepot, it saved around ~10,000 (both numbers after
factoring in the hashes that compared equal but the directory
values differed, as we skip the string comparisons in that case too.)
Time to compile HaikuDepot seems slightly improved, on average.
If system RAM is very low, avoid potentially long waiting for entry
cache to be populated. If entry couldn't be cached, nothing serious
is going to happen.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
The BSD headers prevent using ASSERT definitions in it if we do,
and one will be added in the next commit. Just declare the one
method we need from it instead.
This amends 352548d0a3ce33d0c3bad5e8217ed5f4abc90ced.
If the thread was migrated to another CPU after it was blocked with a
timeout and then was unblocked without needing the timeout, this handler
could possibly race with the thread waking up on the other CPU, resulting
in the other thread thinking it doesn't need to cancel the timer when
the timer is still in the process of running.
May fix #18983.
If we just unblock all threads without actually releasing the lock,
then in the case where all threads have performed the atomic_add
but none have actually started waiting, we'll deadlock forever.
Fixes Mesa deadlocking when using our pthread barriers (at present
it's been using its own.)
This breaks kernel ABI on KDEBUG builds (but not non-KDEBUG builds),
but it does so in order to resolve a long-standing incompatibility
between them: until now, any kernel add-ons built against one which
made use of these lock facilities could not be run on the other;
instead you would get hangs and/or crashes.
After this change, kernel add-ons built with a KDEBUG configuration
should work on a non-KDEBUG kernel, while add-ons built with a
non-KDEBUG configuration will fail to load on a KDEBUG kernel
with unresolved symbols, preventing incorrect and broken operation.
Previously BString::HashValue() had an identical hash to the one
in StringUtils::HashValue(), but now it uses hashdjb2, so this
means Debugger will now use that also.
Tested basic Debugger functionality, seems to still work.
Change-Id: Ia341daa56249967a494df46e6e0a69a74c8b5fe2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8266
Reviewed-by: Rene Gollent <rene@gollent.com>
Otherwise the low_resource thread's run may complete before we
even start waiting, which makes things much slower as we then
have to wait all the way to the timeout.
We should only get an error return code in this method when the mutex
was destroyed, in which case waiter.thread should be NULL.
Also do some minor code cleanups.
May help with diagnosing #18983.
... before the text is loaded by checking that the text document is set.
Remove fMouseDown member and MouseUp() override.
Get mouse button down from the current window message.
Call inherited BView methods.
Fixes #19077
Change-Id: I79edb1860e3bd7864d2362d7f59fb3a583d19053
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8260
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
packagefs StringPool on my system had about 380 colliding string hashes
with the old hash_hash_string (out of ~98,000 strings). With this, it has
only 4, and they're all very odd strings (example: "p16c5x.inc" and
"p16c76.inc" collide.)
(This affects more than packagefs, though; other parts of the kernel
also make use of this routine, including the EntryCache.)
Change-Id: I3cf48a28c5c1a1fb5a457cfaf4fff80029ae146c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8243
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Standard kernel malloc() only uses the block allocator for allocations
up to size 8192, and anything past that has to do a raw allocation,
which is much slower than going through the object_cache.
libroot's readdir() uses a buffer of size 4096, but BDirectory
invokes the syscall directly and allows using arbitrary buffer sizes.
Tracker's AddPosesTask uses CachedEntryIterator which invokes the
syscall with 10 KB buffers, which thus hits this path.
Reducing the buffer size shouldn't be a problem, as applications should
continue calling GetNextDirents() until it returns 0. In case there
are buggy applications, we can simply change GetNextDirents to
call the syscall multiple times if it needs to. Tracker still seems
to behave OK, at least.
If we just use the kernel entry time, then the pre-syscall tracing
routine (with a debugger message send) will be counted in the syscall's
runtime.
Makes the output of timing in strace and strace -c much more accurate,
however it won't include the "syscall overhead" (time spent in the
syscall entry routines, etc.) But we already can't account for time
spent in the userland-to-kernel transition, so that should probably
be measured some other way if knowing it is desired.
In fact, on architectures which used the generic syscall dispatcher
(e.g. RISC-V), this is the behavior that already existed. So this just
makes x86 consistent with them.
Change-Id: I8cef6111e478ab49b0584e15575172eea77a8760
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8240
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Returns an int which is -1, 0, or 1, much like strcmp(). Implemented
as part of the work for using an AVLTree to store nodes, which won't
be merged, but this may be useful in the future anyway.
