The documentation file hadn't been updated in a very long time,
and referred to locks and paradigms that have long since been
dropped (e.g. sMappingLock was removed in 2010, in
afed2658f4ef3e3df5ff8390d1d7a51b5b897a9e.)
Add a few "protected by" comments in VMArea to clarify things,
but otherwise this document looks entirely obsolete (I went
through all of it.)
Before this commit, swap space was committed entirely orthogonally
from memory commitments. This was not handled at all correctly
when cutting areas (the area cutting logic tries to migrate commitments
between caches, but in the case of swapping caches, it didn't,
and couldn't, take the separate fCommittedSwapSize into account.)
Even without that problem, totally separate swap and memory commitments
caused other problems. For instance, suppose a setup with 4GB of RAM
and 4GB of swap. Many caches are created, and all 4GB of swap gets
reserved, but the caches with this swap reserved have no or few pages
in them. Then, all 4GB of RAM gets used up. The page daemon runs, and
looks for things to swap out, but it can't find anything because all
our swappable caches with pages have no swap reservations, so all it
can do is flush out cached pages, which just degrades performance.
Or, consider what would happen if the 4GB of swap was released, but
the 4GB of RAM was still in use, and then the kernel tried to
allocate memory. It would get OOM errors, because none of the
caches have swap commitments and so nothing can be written out.
Under this new system, the specific swap space reservation only happens
just before the page is first written out, so both these cases should
be handled smoothly, and swap should be used in a much more sensible
fashion overall.
This change seems to be more in line with what other OSes do (Windows
Task Manager's "Committed" clearly is RAM+swap, for instance.)
The only potential downside to this change is that swappable caches
may temporarily go over their commitment when reading or writing
out pages to swap, before the page daemon has a chance to come by
and free the page or the swap space. But as that is a temporary state
and should always be resolved by the page daemon, I think it's
probably an acceptable trade-off.
Change-Id: I928f4b4cacbec26ed6315179476eaff1a7f626c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10305
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This will be useful in the case of cloned device caches based
around physical memory, e.g. for framebuffers.
Change-Id: If2b864208e86f436e91379b73c4b866b0bd5e1d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10558
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Instead of the kernel heap being a compile-time parameter, make it
a runtime parameter (if DEBUG_HEAPS is specified, at least; otherwise
we're hardwired to the slab heap as before.)
This is similar to what's done in userland: there LD_PRELOAD and
MALLOC_DEBUG control the heaps, here "kernel_malloc" and then
"guarded_heap_options" kernel settings control the heap.
While at it, apply fixes to the guarded and debug heaps to ensure
a minimum alignment of sizeof(void*), if no specific alignment
is requested.
Tested with a lot of build configurations (DEBUG_HEAPS 0, 1;
DEBUG_HEAPS_DEFAULT slab, guarded; USE_DEBUG_HEAPS_FOR_OBJECT_CACHE
0, 1) and with various parameters specified in the bootloader.
* Insert/Remove can't fail, so drop status_t return values.
* "TransferAreas" is really "TakeAreasFrom", so rename it. This
avoids confusion with the "transfer_area" API call, which moves
an area to another address space (keeping the same cache.)
* Give arch_vm_supports_protection a team_id argument (primarily
to allow the kernel address space to be more restricted than
user ones.)
* Move invocation of arch_vm_supports_protection to a static method,
and also call fix_protection from there.
* Consolidate protection checks.
* E2H (EL2 Host) is enabled by default and usually can't be disabled
on CPUs with FEAT_VHE. Since EL2 becomes a superset of EL1 with
E2H, we can simply do nothing and everything that expects EL1
will Just Work
* Changed some register bits numbers to avoid C integer promotion
issues
* sEmptyTable needs to be filled in earler, before the kernel team
is created. Otherwise, we put the uninitialized value of sEmptyTable
in TTBR0, which immediately pends SError on Apple M1
Change-Id: I84ff7fd9134448f27315dadfd12bdd9df8c75b10
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10547
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
These allow us to move a lot of the basic logic out of the
TranslationMaps. In the process, it extends the fix applied
to x86 in the previous commit to all the other maps.
Following upon a KDL reported by atomozero, on wait-for-free-SMP-messages
on an unblock occurring with interrupts disabled.
In changing cpu_ent, move disabled to the beginning to avoid
enlarging the structure unncessarily.
On a 4-core VM, this skips around 200 sends during boot, and
over 3000 during a rebuild of HaikuDepot + mime_db (cold). On
bare metal (i3, 2x2), it skips around 150 during boot, and a bit
below 3000 during a rebuild of HaikuDepot + mime_db (over a much
longer time than in the VM, as the hardware is slower.)
Performance in the VM doesn't look much different. But this might
help in VirtualBox, or other situations where ICI latency is far
above what it should be.
Since the methods now don't just "send", the names are changed
also (which is fitting since they're now API-incompatible.)
The changes in the TranslationMaps to adopt this fixes a correctness
issue: previously TLB invalidations would be done either with or
without interrupts enabled depending on how they were invoked.
Now, they'll always be done with interrupts disabled. (This is
the same fix that was recently done to x86.)
The idea with processing the ICIs on the current CPU too is
that presumably the other CPUs will take just as much, if not
more, time processing the ICI than the sending CPU. So, we might
as well do the processing while we wait, rather than before or after.
Testing shows this to indeed be the case. On a bare metal i3, kernel
map invalidations (with global invalidations always forced) across
a boot-to-desktop go from around ~60.8ms cumulative before,
to ~51.8ms cumulative after this change.
Change-Id: Icd0343d462de7cf11043e6438f47b02f6b88bb8b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10472
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Currently the IO-APIC is fully initialized after PCI initialization
resulting in the IO-APIC not being initialized on systems without a
PCI bus (i.e. Hyper-V Gen2 VMs). This change moves IO-APIC
initialization to occur during early init, deferring PCI interrupt
enumeration and routing until after PCI initialization has been
completed.
Change-Id: I00be0be05d2e7668c3c6bc7af3afc4ff8d04a129
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10414
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: X512 X512 <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Since the kernel is built with -ffreestanding, and thus -fno-builtin,
the compiler ignores the function names and doesn't perform optimizations
(e.g. inlining for small values) that it otherwise could. So, here,
we add a string.h that supplements the default, and uses #define to
reinstate the builtins, and thus the optimizations.
Linux and FreeBSD at least apparently do the same. A quick compile
benchmark in a VM doesn't show much difference, maybe a slight
decrease in sys time.
I checked all invocations of GetBit; as far as I can tell,
only the two adjusted here in smp.cpp are done while the Set
may be concurrently modified, and even then I don't know
that they really need to be atomics, anyway.
This allows us to gracefully fail if memory allocation fails,
rather than panic()ing. If a single-threaded application tries
to wait on a non-shared user_mutex in single-threaded mode, it
will now be dropped into the debugger.
Fallback to DBG2 if SPCR is not present while discovering UART serial
devices. DBG2 is newer than SPCR but does not provide the same
information, and it appears that both can exist on the same system.
This has only been tested in Hyper-V which exposes DBG2.
Change-Id: I6a75114f4287b6db289b544c3b80a66a625fb6c6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10354
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
This will be useful on architectures that support ASIDs, and on
ones that don't, it can be used to avoid a race between invalidation
messages being sent and context switches occurring on other CPUs.
In this commit, no behavioral change intended on any architecture.
Change-Id: I6d2ee4b69150f9ff8503329761266ddbdb550eab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10349
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Similar to open firmware implementation.
This allows to load the kernel from a remote_disk_server.
IP address is recovered using LoadOptions with a syntax similar to the
Linux kernel network boot "ip" parameter. If this is not set, no network
booting is attempted, in order to not slow down normal booting by
waiting on network traffic.
Change-Id: I17738bbcde85921672965b9936a2b484f1e57c6c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3678
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Tested-by: Commit checker robot <[email protected]>
The uart virtual address changes as soon as we apply the kernel memory
map. gUART is used only after that, from serial_init() onwards. So it
should use the virtual address, and not the physical address it was
previously created with while parsing the FDT.
Change-Id: I8c8a024fe564b49d6555f8e48f5ab31652d30708
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10068
Reviewed-by: Fredrik Holmqvist <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
They're not needed anymore. The VMTranslationMap method was confusingly
named anyway, as the other Debug* methods are for use in KDL, while
this one required the regular locks and flush mechanisms.
Change-Id: Ic1baf3d786071562d8beaeb768d996cd1d34f9b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9706
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* prefer v3 over v2
* adding efi attributes in gBootVolume KMessage is a bit of a hack, but
shouldn't hurt older kernels.
Change-Id: If5ea19dafa5a845872eb8d577e77a6935539ce20
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9685
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested by OscarL and confirmed to be working on at least
one machine, though on others it hangs, so leaving out
of the default builds for now.
This adds an "acpi_processor_id" field to x86 arch_cpu_info,
gleaned from the MADT, so we can match our cpu_ents to ACPI
processor objects. (FreeBSD does a similar mapping, see
their acpi_cpu_probe method.)
Change-Id: Idb5e3c1fc1efaa4256d60ea17dd1824345369687
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9637
Reviewed-by: waddlesplash <[email protected]>
This should make use-after-frees more likely to be caught by the
standard paranoia facilities (and make them less likely to be
exploitable as memory will take longer to be reused.)
These instructions are only available on more recent CPUs (MWAITX
on AMD since around 2015 or so, TPAUSE on Intel since around 2020.)
They allow idly waiting on the TSC even when interrupts are
disabled.
Most hypervisors do not have these available (KVM does provide
them, though not on all configurations), but on bare metal this
should make a nice difference to KDL power consumption: I tested
with a Ryzen 3700X, according to my UPS (so including monitor
and peripherals) the system used ~106 W at idle, 160 W in KDL
before this patch, and 125 W in KDL after it.
Change-Id: Id7a22ecd33f3fc005b2c312f945dc3cd364e96fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9604
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The idea is to add a facility that will use less CPU than
the loops we currently use. The default implementation just
calls spin(), which is rdtsc+pause. This already may save
some power compared to what we previously did, which was to
re-check serial ports, PS/2, etc. every single loop in
the debugger, broken up only by "pause".
Change-Id: Ie421adae5c25ad6ae0c266d1d28c2ea7b81ae465
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9603
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This massively cuts down on lock contention in Add(), since insertions
only acquire a write-lock in the case where a generation rolls over,
same as Lookup() does.
"git status" in buildtools, cold disk cache in a 4-core VM, seems about
the same, maybe slightly slower (~0.5s seemed typical, out of 20-21s),
while with a hot disk cache it's much faster: ~9.8s -> ~2.4s. Compile
performance seemed about the same.
Change-Id: Ia73f35fbbad3b3ac9ed783ea38cb8e2cb9818b5b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9580
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
x86_64 already does this and it seems to work fine. Since stack areas
grow downwards and should always have a guard page, overruns shouldn't
be too much of a concern (for that matter, randomization still makes
a difference here also, it seems.)
This allows us to regain another ~256 MB or so of contiguous address
space (areas smaller than that could still be inserted in the 0x6.. to
0x7.. block, but if you had 10MB of free address space below 0x6..,
and 246MB above it, you couldn't allocate a 256MB block.)
Part of #19592.
Augustin Cavalier