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>
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 <waddlesplash@gmail.com>
Will be used in following commits.
Change-Id: Ica89d28cbf6980aca8dc347dfdcb200a0e637e9a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8442
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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...
_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.)
* This is needed in order to support syscalls and other exceptions
that need to be able to inspect/modify userspace register contents.
Change-Id: I8a638c0c40dd44ed882adad0591ae3bf5493a6b9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8329
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Using the page attribute table to set the memory type on a per page
mapping basis is the more modern and flexible approach to physical
memory type handling compared to using MTRRs.
Most of the needed infrastructure was already in place, as setting the
page table entry attributes was already done for uncachable and
write-back memory types. Using the PAT now also allows to set the last
remaining memory type of write-combining through the PTE flags. The PAT
is configured to have entry 4 mean write-combining and the PAT bit in
the PTE is set to point to that.
When PAT is supported and not disabled, MTRRs are completely ignored
and left as set up by the system firmware, where the basic uncachable
and RAM ranges are supposed to be set up. These configurations are then
overridden by the PTE flags as needed.
Change-Id: I0a74b3fc7d3ba9fa384251290ce41621b69d3a02
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8340
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We allow requesting an explicit memory type when calling
map_physical_memory but default to the uncached B_MTR_UC when not given.
When called without an explicitly requested memory type, allow
arch_vm_set_memory_type to modify and return an effective memory type.
When an overlapping range already exists, the effective memory type is
set to the one of the existing mapping. If there is an explicit memory
type request that conflicts with an existing range, or if multiple
overlaps with conflicting types would be produced, the mapping is
disallow (and a panic is triggered under KDEBUG).
This effectively detects and panics when conflicting aliases of physical
memory would be created. This is also useful on an MTRR based setup,
as such overlaps cannot be properly represented.
When using the page attribute table (PAT) to set the memory type on a
per page virtual memory mapping basis, this is needed to prevent
aliasing of the same physical memory with different types. As per the
specs, such aliasing is unsupported and may result in undefined
operations that lead to system failure.
The mechanism is extended to the general arch_vm_set_memory_type as such
aliasing prevention also seems to apply to other architectures (at least
on ARM, aliasing is also strongly discouraged).
Change-Id: I7aaf6ea8415e92e74cd1643b67793a6857619eea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8339
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 0caf23319c.
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>
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.
