It's been broken since clone_area was changed to block cloning of
areas without B_CLONEABLE_AREA set on them. We here introduce a
B_DEBUG_MESSAGE_CLONE_AREA debug nub message, which clones the areas
of the debugged team for the debugger.
Also fix some bugs in SymbolLookup::_FindLoadedImageAt methods:
they didn't work properly when *next was NULL, so they would
always fail when iterating over the full list.
Note that this technically breaks libdebug.so and the debugger
protocol ABI. However, nothing out-of-tree that I know of uses
the private libdebug.so, and while GDB does use the debugger
protocol, it doesn't actually use any of the messages past
the first block, so it should still work after this.
Fixes #15251.
Change-Id: I71ccbee4afd17dae30d5dacbc7590d1e2175a90e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8821
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is more efficient and works most of the time. Additionally,
we can potentially join with a previous free chunk in the allocator,
avoiding extra fragmentation on the heap.
app_server (on x86_64) only has 1 "rld heap" area after this change
with a size of 0x50000 (320KB), whereas previously it had around 7
with a total size of 0x80000 (512KB).
The old define was really "check heap integrity", so it's split off.
In the userland test harness, this takes the total time spent in
the allocator from around 1ms to 14ms for all the allocations used
during a boot with "nightly" profile, so it seems acceptable to
enable it under KDEBUG.
Tested with both BIOS and EFI bootloaders, still works.
They were mostly copies of one another, save for the glue code
and a few other things. Now they're mostly unified, and this allows
the test to be greatly simplified, too, since it can avoid including
any bootloader code at all.
The heap implementation itself should have no behavioral changes
from before. Those will come in future commits.
They were hand-rolled singly-linked lists before. This adds 24 bytes
of size to the Team structure, but turns all the removal operations
in parent and process group into O(1) operations instead of O(N) ones.
Realistically, the Thread linked-lists should be converted as well,
but this is trickier due to interdependence on the Team structure.
At present there's only ever one global one, so we don't bother using
an array for multiple screens (and we don't support multiple screens
yet anyway.)
This fixes a very old TODO, and avoids sending a ~32 KB port message
on every application startup.
Note that this breaks the app_server protocol ABI.
We already didn't inherit FDs, which meant that the only thing we
did meaningfully inherit was the table size. That meant that basically
no applications actually had a table size of the default 256, but all
were at the kernel's 4096 (except Tracker and anything started by it,
as Tracker resets it to 512), and also that basically all applications
had FD tables allocated with the raw allocator instead of the block
allocator, which isn't very efficient.
Since this reduces the default FD table size, some applications
might encounter problems. However, build systems and other such
tools should already increase this by default as needed, and it's
easy enough to patch in calls to setrlimit() if it turns out
some applications needed a higher default after all.
Also remove a redundant call to vfs_exec_io_context. Calling
vfs_new_io_context with the second argument set to "true"
already skips cloning CLOEXEC FDs.
Zstd wants a ~90 KB scratch buffer to decompress our 64 KB chunks.
Rather than let it allocate that itself every time, pass in a 2*64KB
"scratch" buffer and statically allocate the working memory from it.
Pass it down using iovecs, and pass down the other buffers in the same
way, to reduce parameters.
Further, rework the object_cache used for heap decompression buffers
to contain objects sized as 4x64KB, so we only need to do one allocation
and deallocation for the compression/decompression and scratch buffers.
Set the minimum reserve to 1 so that the low-memory manager doesn't
reclaim this, as we'll need it when reading back data.
Improves packagefs I/O performance (and thus boot speeds at least a bit,
it appears.)
Change-Id: Id51f6f598b33b9d757a283184c533bb97049529f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8717
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This adds some new parameters to UnmapPage and UnmapPages. The important
one is a "_flags" pointer to UnmapPage, which if specified will be
filled with the page flags instead of PageUnmapped() being called
(and Flush() won't be invoked, either.)
This removes the remaining PAGE_STATE_* changes from VM architecture code.
Change-Id: Iacbc424dd8a75a79986edcd7f04d15a10f773c87
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8728
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
An extra argument is added to allow the VMAreaMappings objects to
be added to a queue instead of freed directly (and the lock unlocked,
and so on.)
All architectures adjusted.
This means there is now only one place in each TranslationMap that
the page state and other data is directly adjusted (in UnmapArea).
Change-Id: I3ed2d6d969d1b1e235144a1035c90c750779af27
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8716
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Nothing uses it, and it isn't correct anyway: vm_page_num_free_pages()
now includes cached pages, too, while vm_available_memory() includes
not just available memory pages but also swap.
This reverts a8877df135.
Previously, the "unmergeable" flag was necessary for the RAMFS,
because if the last vnode reference was released while there
was still a consumer (as the old ordering of _RemoveConsumer
had), then the release of the cache reference when the vnode
was removed would result in the cache trying to merge with
its now-only consumer and sole referrer.
Now, instead, we remove the consumer before releasing the store
reference, so that there's no chance the cache will be merged
inside this method.
mmap_cut_tests still pass, web browsers using ramfs shared_memory
still seem to work.
Otherwise, platform loaders couldn't make heap allocations inside
platform_start_kernel(), which some loaders (e.g. EFI) do.
Implement calling heap_release() for the BIOS loaders at least.
This gets us back the ~1.5MB of bootloader heap memory there.
Overcommitted caches should only have commitments equal to the
number of pages they actually contain, so we should decommit
whenever pages are discarded.
This changes the API of VMCache::Discard to return an ssize_t
of the size of pages that were discarded (or a negative error on
failure.) Nothing checked the return value besides things in VMCache
itself, it appears; but it apparently never fails, so that's fine.
Also add asserts to Commit() that the new commitment at least
encompasses all pages the cache actually contains.
"Move" now sounds like it has 'move' semantics (i.e. replaces this
structure's data with the other structure's data), while MoveFrom()
really had 'move+append' semantics (appends the other list's elements
to this list, and clears the other list.) To make this clearer, it's
here renamed to "TakeFrom".
This should reduce confusion with the other move-related APIs that
are starting to show up in the Haiku tree (e.g. "MoveFrom" in BRegion.)
Change-Id: Ib0a61a9c12fe8812020efd55a2a0818883883e2a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8634
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 X512 <danger_mail@list.ru>
This reverts commit 1db0961121.
It turns out the comment is not obsolete; what it refers to isn't
PAE systems but true 32-bit ones. I'm not sure we should use
64-bit cache offsets even there, but that's a decision for another
time.
Previously, lower was better, and higher was worse. But really we want
the scores to be based primarily around the index sizes, which can
grow to be very large, so a maximum score is hard to determine.
Instead, start with the index size, and then divide to make it smaller
based on how "useful" the equation terms will be in searching it.
Improves the performance of queries like those in #19080; according
to humdinger's testing, the query with the most expensive term first
went from ~2.0s execution time down to ~0.7s, same as the query with
the least expensive term first.
Change-Id: Id71fa21c95cfe3d8d0019ff356bdf4935446411f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8593
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
B_PATH_NAME_LENGTH == PATH_MAX, and PATH_MAX is inclusive of the final
NULL terminator, so we don't need a + 1 here.
The original KPath default was to not use + 1, but that was changed in
42e3c6f978 due to all the consumers that did.
But all those consumers are wrong, it appears; they should just be
using the default length instead. So now we do that.
* If we coerce types inside the switch(), then the "type already converted"
check at the beginning will fail every time, causing us to reconvert,
which is surely bad for performance.
* B_TIME_TYPE should be INT32 or INT64 depending on what its size is.
May help with #19080.
Previously it was not initialized until "post-VM", but there are
a number of ways VM initialization can go wrong that it would
be nice to know about without needing a serial port.
On arches which map the whole physical memory into the kernel
address space (x86_64, at least), we can get the bluescreen facility
initialized using KERNEL_PMAP_BASE. On other architectures, we
just fail to init then, and do the usual setup later on.
A slight bit of extra code cleanup in blue_screen_init_early:
we now just call module->info.std_ops() rather than a
frame-buffer-console specific method.
Applications that don't call open() or like functions too often,
and call many FD-related methods across multiple threads at once
(like "git status") now don't wait on the context lock as much.
("git status" performance isn't much improved because threads just
hit the "unused vnodes" lock instead.)
* Allocate blocks and add them to the hash table so they are
available for a future block_cache_get call.
* Make use of prefetching in FAT driver.
* A client filesystem may request to prefetch a block run that
contains some blocks that are already cached. The request will
be truncated at the first such block in the run.
* Fixes #19186.
Change-Id: I8d2e3cff15e5b46569438e0dc085e2b391aa57a5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8525
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Avoid declaring random friend classes in public header. Allow to access
private methods from arbitrary source if needed.
Change-Id: Iac2cf0ca59e483aa0657e3fe1fc47080c661cf8b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8534
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This way, modules can decide to do different things based on having
all the ancillary data available. In particular, the UNIX module will
now post only one message header for all the FDs, even if they came
from multiple sets of ancillary data.
This should fix "Message needs unreceived descriptors" from the Chromium
IPC code (which is used by Firefox).
* add SOCK_NONBLOCK and SOCK_CLOEXEC
* also extends the type parameter on socketpair() and socket()
Change-Id: I73570d5bfb57c2da00c1086149c9f07547ba61ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8515
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Add kDeleteSelection command alias in Commands.h, keep kDelete.
* Add kMoveSelectionToTrash and use it in place of kMoveToTrash.
- kMoveToTrash in kept in tracker_private.h for use outside.
* Create a new constant kRestoreSelectionFromTrash for Tracker.
- Move kRestoreFromTrash to tracker_private.h
Change-Id: I3cdefe97e8359fb53bacfc3319b046b051c6f7db
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8225
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>
