We set flags above the timeout check, so we need to use |= and
not lose the SHARED flag we already set.
Fixes some testcases in the POSIX testsuite, and the shared
semaphore code in Gecko/Firefox.
Except on kernel_cpp.cpp. We don't use it for most of libroot, so
we don't need it for most of runtime_loader either. The two preceding
changes were all that's necessary to fix things with builtins enabled.
Very slight performance improvement (the "run 1000 shells" benchmark
seems to decrease by about 0.4 seconds out of 16.5 or so.)
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.
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.
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 352548d0a3.
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 <[email protected]>
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.
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 <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
Tested-by: Commit checker robot <[email protected]>
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 <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
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.
On my development VM, there were over 300,000 calls to malloc()
from EntryAttributeHandler::HandleAttribute() alone, which had
the most out of any AttributeHandler, but the others were still
significant (over another 10,000 at least.) On systems with more
packages and more attributes, there would be of course more calls
to malloc().
Since the Handlers are allocated and freed in a "stack"-like
configuration, we can use a simple "bump" allocation strategy
with the AttributeHandlerContext to avoid calling malloc() at all.
In my testing, the most memory that was used appeared to be around
2 KB or so (and the smallest was 216 bytes), so a single slab
should suffice for this.
AttributeHandlerContext seems to be created/destroyed around 530 times
during the boot process on my test machine; allocating and freeing the
allocator's slab page that many times should be negligible (allocations
that large still go through the block allocator.)
Performance-wise, the total time we spend with AttributeHandlerContext
objects "alive" goes from around ~172ms to ~156ms. So, not as much an
improvement as one might hope, but that just goes to show that our
kernel malloc() is pretty efficient. And this change will also keep
short-lived objects off the heap during a period when we are allocating
many long-lived objects, anyway.
Change-Id: I810888434aad788511f2af30143335009b34ee78
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8230
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
A basic bump allocator that can handle arbitrary amounts of allocations,
so long as all are allocated and freed in a "stack"-like manner.
(Actually it could be extended to support non-stack-like operation,
but that would require more logic that isn't needed at the moment.)
Change-Id: I47077146ea282600130778d312f7d86bd8c032e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8238
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Michael Lotz <[email protected]>
Anyone I've moved, I didn't see any signs of code contributions
or reviews, tickets, or forum posts in the last year and a half
at least. They may still be around and reachable, but I don't think
that suffices to be a "Haiku maintainer".
I've also moved Alexander up in the list of maintainers; the "Past"
list doesn't seem to count "von" for the alphabetical sort.
There was also one mis-sort in the past list which I've fixed.
Change-Id: If6763372be6a23b24bc0f781243e198d1734a849
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8239
Reviewed-by: waddlesplash <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
Tested-by: Commit checker robot <[email protected]>
We unfortunately have to define its methods in the .cpp and not fully
inline them, because otherwise GCC chokes in some places thinking
that the class can be NULL (where it can't be) and thus generating
overrun -Werrors.
This reduces the size of Node and all subclasses (like UnpackingLeafNode)
by 8 bytes. (Not 16 as with PackageNode, as it doesn't eliminate a
virtual table pointer.)
BReferenceable has a vtable, so it's aligned on sizeof(void*) and thus
has 4 bytes of padding on 64-bit systems. We also had 4 bytes of padding,
and so if we just inline an int32 and add Acquire/Release methods,
then we save 16 bytes (again on 64-bit systems) of object size.
Since this isn't so obvious, add an inline comment explaining the
situation.
This makes sizeof(PackageFile) go from 112 to 96 bytes, and so on.
We don't really need nanosecond resolution here, microseconds will do.
We can thus fit the value into bigtime_t and use the standard converters.
Reduces the size of PackageNode by another 8 bytes on 64-bit,
saving another ~2.5 MB of memory (or so) on my test VM.
Change-Id: I1232aa8aa22fbf84a6a70af0129183f297961f03
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8237
Reviewed-by: waddlesplash <[email protected]>
* Rename NumBlocks to NumBitmapBlocks, as this is the number
of blocks in the block bitmap, not on the filesystem.
* Rename AllocationGroup::Block(index) to Chunk(index), as it refers
to a "chunk" of 32 bits within the bitmap block. This gives us
one less usage of the term "block" in this file.
* Remove superfluous comment.
No functional change intended.
Change-Id: If736387fcd9963a4a74bb0dde12ede81da5502f3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8185
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Axel Dörfler <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
We never actually remove these (except on destruction) and only
iterate over them sequentially, so just use a singly linked list.
Combined with previous changes, this reduces the size of NodeAttributes
from 64 to 48 bytes (on x86_64).
So that it has the same naming as DoublyLinkedList.
No functional change. It seems there aren't any users
of this API in the default build at the moment.
* PackageData::fVersion is (for now) static const, until such time
as there's a HPKGv3.
* Remove locking from DataAccessor as it was only needed for V1.
We want them for the heap buffers, but the rest will generally only
be used when other packagefs locks are acquired (during mounting
or unmounting of packages), so the depots are just a waste.
According to the POSIX specification:
> The sem_timedwait() function shall fail if:
> [EINVAL]
> The process or thread would have blocked, and the abstime
> parameter specified a nanoseconds field value less than zero
> or greater than or equal to 1000 million.
Fixes#16693, #16694.
Haiku's Be-style semaphores have a global limit, but the
POSIX-style semaphores do not. Functionally there will be a limit
as to how many can be waited on at a time, but one will probably
hit thread limits before that happens.
This matches what FreeBSD does: specifies 256 for _POSIX_SEM_NSEMS_MAX
but then returns -1 for the sysconf value.
Fixes#16692.
If a multibyte Unicode character is specified to MultibyteToWchar
one byte at a time, then resetting the state will lose the data
for the second character. We thus shouldn't re-read but instead
keep the existing character and just read the second one.
Fixes#19035.
Otherwise, when the current locale timezone is one that has
an offset to GMT of 0, we would wind up with its name in tm_zone
and not "GMT".
Follows up to #19047.
We can be called with a timezone that isn't the same as the one
set in the current locale, in particular from gmtime(). We thus need
to handle this case properly by checking that the gmtoff is really
the timezone in the locale, or if it's GMT, to just use a static
string for the tm_zone instead.
Fixes#19047.
-1 was our previous value for AT_FDCWD, so we should retain support
for it here for the moment. All other negative values will now result
in an error.
Part of #19048.
The local transferEndOffset should be relative to the parent (us),
not to the underlying filesystem. We thus need to subtract our
own offset from the operation's offset.
This fixes a regression from be8080575a.
Errors transferring data should now be properly reported in more cases.
Some things that call these macros put expressions in them; to avoid
operator precedence problems we should put them in parens.
Change-Id: I57335ffb190c484778c4bc8075d5ca3597f1e7e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8184
Reviewed-by: waddlesplash <[email protected]>
Augustin Cavalier