This way, the Pipe won't be seen as "idle" when there are still
transfers in flight with references to it.
May help with diagnosing or even outright fix#17549, #18768, #17799
and #17348.
This avoids leaking the bootloader heap memory into the kernel.
Ideally it'd be dropped automatically, but in seems in many cases
it isn't (even on EFI).
Adjust platform logic to always remove the physical allocated range,
and ignore the return code and reuse the memory anyway if we can.
Previously, there was only platform_init_heap/platform_release_heap,
which allocated a single static heap region for the heap to use,
and any subsequent heap allocations had to go through the standard
platform_allocate_region, which allocates regions visible both
to the bootloader and the kernel.
But as mentioned in previous changes, it isn't always easy to
release regions allocated that way. And besides, some bootloaders
(like EFI) use a completely separate mechanism to allocate
bootloader-local memory, which will never get "leaked" into
the kernel.
So instead, refactor all platforms to instead provide two
new methods: platform_{allocate,free}_heap_region. On EFI
this is easy to implement; on most other platforms we have
logic based more on the old platform_init_heap or allocate_region.
(On the BIOS loader in particular, we can only fully release
the memory if it's the last thing we allocated in the physical
addresses. If the "large allocation" threshhold is lowered
back to 16 KB, then we are unable to do this enough times
that we will run past the end of the 8 MB identity map and
thus fail to boot. But with the larger threshhold, we don't
leak nearly as much, and don't hit the threshhold.)
This should further reduce the amount of bootloader memory
permanently "leaked" into the kernel's used memory, though
on some platforms it may still be nonzero.
Change-Id: I5b2257fc5a425c024f298291f1401a26ea246383
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8440
Reviewed-by: waddlesplash <[email protected]>
It should be OK to call this during kernel startup without using
reservations, since it's mostly used for fixed memory ranges
specified by the bootloader.
Also turn a later dprintf into a panic.
page_num_t is typedef'd to phys_addr_t, so it's 64-bits on 32-bit
platforms with PAE. In fact it's been so since the introduction
of phys_addr_t, so this comment was obsolete from the start...
If the existing allocated ranges are from physical memory ranges that
are just too small, then we'll need to start a new "allocated" range
based on the next-available physical memory range.
Should fix the "PANIC: error allocating early page!" tickets
(i.e. #14659 and friends.)
Not all platforms can properly release memory allocated via
platform_allocate_region() at present; in particular the BIOS
loader seems to (at least partially) leak it. And due to how the
kernel args ranges are handed off to the kernel, it seems
allocated physical pages that aren't virtually mapped are
leaked at present as well.
That seems like a bug that we should likely fix, and moreover
the heap shouldn't use that facility at all (but instead
request bootloader-local memory if possible; on the BIOS
loader that will ultimately go through similar logic, but
on e.g. EFI it will be entirely separate.)
But in the meantime, we can just increase the size of the
"large allocation" threshhold so that packagefs temporary buffers
(of 64 and 93 KB) stay on the main heap, and don't hit that
facility at all. The "maximum boot loader heap usage" seems
to go up by about ~200 KB with this change (e.g. 588 KB -> 797 KB),
so increase the default heap size by 256 KB to compensate.
This fixes most of the rest of #14831: memory usage after the
boot has finished is down by over 100 MB (!). The remaining
problems and leaks can be dealt with in later changes.
This reverts commit 13a5c7f91f,
and adds an inline comment explaining why this actually isn't allowed,
despite "working" in most circumstances.
Doesn't affect anything in default builds (KDEBUG_RW_LOCK_DEBUG
is not enabled under KDEBUG.)
We already started at the first-free in the block bitmap, but
after that we would just check individual bits as we went along.
Now we skip forwards to the next free block when encountering a
used block, by comparing to UINT32_MAX (all blocks used) and using
ffs() with a bitwise NOT (to find the first unused block in a chunk.)
This will benefit fragmented partitions more than non-fragmented ones.
I didn't see a significant speedup on my compile benchmark in a VM.
Fixes#18929.
X512 tested this patch and confirmed it reduces CPU usage on a
partition that he saw long times spent in AllocateBlocks on.
Change-Id: If71b5e24c585c2cc08879c8aefc80af8ae7da91f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8186
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This saves 40 bytes from the size of Node (on 64-bit architectures.)
UnpackingDirectory is still at 200 bytes, while UnpackingLeafNode
is now 96 instead of 136. This saves ~5MB of memory on my system
(UnpackingLeafNodes go from 16.2MB to 11.2MB.)
The general strategy is for Directories to use their own locks, while
all other nodes read-lock their parent directory during use. There are
a few edge cases around node creation and removal in the case of
non-directory nodes; see inline comments in Volume's
_RemoveNodeAndVNode as well as packagefs_put_vnode.
Since it's now possible for a node's parent to change or be deleted
when we don't have the lock (but only a reference), we need a lock
protecting just that field to hold while we acquire a reference to
the parent. (Right now, this is just one static rw_lock for all Nodes;
this could be changed in the future if necessary, but it seems performant
enough for the moment.)
Tested with basic system functionality, installing/uninstalling packages,
uninstalling packages with files still in use, HaikuPorter builds, and
more. All still seems to work as expected.
Change-Id: I054187316c66b77ea1951c6d1ea8e5b75715c082
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7930
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* When the page_protections array is allocated, we should clear the
protections from the area's flags, since they aren't used for
anything when the page_protections array is activated.
* When set_area_protection is called and there is a page_protections
array in use, it should be freed, and we should reset the protections
on all pages.
* Add some tests related to these behaviors.
Otherwise, all RAM that has a more specific type than the physical range
will hit the assertion below. We also don't want to return the type
set here, so put this check before the effectiveType check.
Change-Id: I703242221771732c69accce66380b5a0efdc77e3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8345
Haiku-Format: Haiku-format Bot <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Iterating over every single page in a 64-bit address space is far
too expensive. Instead, use DebugGetReverseMappingInfo(), which
iterates over the page translation map's page tables.
(The only thing that implements this at present, however, is
X86VMTranslationMapPAE, so it won't be too useful on 64-bit
just yet. But at least we won't hang for very long periods
of time on 64-bit at least.)
* Trim down comment about fno-delete-null-pointer-checks.
* Remove -fno-builtin-fork -fno-builtin-vfork, they don't seem
to be needed with GCC 13.
* Remove legacy-GCC settings from kernel flags, as we don't use
legacy-GCC there anymore. Also drop fno-builtin as ffreestanding
implies this.
This breaks kernel C++ ABI.
This mostly just changes the definition (not the size) of string types,
but in at least one case (daddr_t) it does change the size (from 32-
to 64-bit.)
_BEOS_R5_COMPATIBLE_ was defined in ArchitectureRules while
__HAIKU_BEOS_COMPATIBLE is defined in HaikuConfig.h (which is
in the include path for sys/types, SupportDefs, and other
base headers.)
The don't-wait and do-wait logic was very similar except for the
actual acquisition of the lock in the middle, so now they're combined.
This fixes another (minor) regression from 9e89f7c068
in that if a page's cache changed before we acquired its lock and
don't-wait was set, we would wind up waiting anyway.
This fixes a regression from 9e89f7c068.
Even if SwitchFromReadLock fails, the original read lock has been released,
and so we need to re-acquire the lock before continuing.
Should fix a KDL reported by X512.
* Put disabled code behind #if 0 instead of comments, as per style guide.
* Clean up comments.
* Errors should be ERROR not INFO (but both are printed anyway
at the moment.)
No functional change intended.
We automatically enable _DEFAULT_SOURCE if _GNU_SOURCE is defined.
Rather than having even more optional methods undefined unless
_GNU_SOURCE manually is, just change all remaining guarts to
use _DEFAULT_SOURCE instead.
Fixes#19095.
Change-Id: I5c7baf40b7fb37913e24279589fc1ae706448a45
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8330
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
The names chosen (e.g. "B_UNCACHED_MEMORY") follow the existing naming
conventions for memory-related constants, of putting the type at the end
of the name: B_KERNEL_BLOCK_ADDRESS, B_FULL_LOCK, B_READ_AREA, etc.
Resolves a very old TODO. No functional change intended.
Change-Id: I31491f6b3abc1e95f915aa302b9f2fb2af14774c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8316
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
It's needed in delete_area for arch_vm_unset_memory_type at least.
Instead just add a parameter indicating the area is already removed
from the areas map.
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.
Augustin Cavalier