* 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.
It isn't needed now that it's set before sending the ICI. Saves
a lot (hundreds, in some basic testing of compile jobs) of
unnecessary scheduler invocations.
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.
We may be called from the page daemon, which may be running on
a different CPU than the one this map is active on. So don't
bother flushing unnecessarily if we can avoid it.
This avoids the broadcast mailbox (and the incrementing of
other CPU's counters) entirely in this case.
As this is used for TLB invalidation, processes that are only
running two threads at once will benefit immensely from this.
It also seems to be triggered by the kernel's "idle_scan_active_pages"
logic, which sometimes sends invalidations to CPUs besides its own.
On the VM setup, this path was hit around 200 times during boot,
around 600 times during a rebuild of HaikuDepot + mime_db, and
50,000+ times while running Iceweasel (Firefox). On bare metal,
it was hit around 300 times during boot, 300 times during a rebuild,
and 90,000+ times while running Iceweasel (over a different length
of time, though.)
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]>
The homegrown usb_asix was partially based on the upstream FreeBSD
driver anyway, and hasn't seen much maintenance in recent years.
We might as well replace it with the FreeBSD version. In the process,
also add the "axge" driver, supporting the Gigabit version of this
hardware.
Tested by smrobtzz with the AX88179A: "it seems to work perfectly".
Change-Id: I37fdfc2cef6100916d6034817f117286f7f443b2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9600
Reviewed-by: waddlesplash <[email protected]>
Also delete an OpenBSD compatibility section that isn't used.
This includes a fix to mbufq_full (made in 2019 in FreeBSD)
to allow for mbufqs of unlimited size, apparently needed by
some drivers, found by @smrobtzz while testing USB ethernet
drivers.
The SMP_MAX_CPUS * 4 fixed pool size apparently goes all the way
back to NewOS, which supported only 4 CPUs max. As ours is now
64, this means the fixed pool size was very large even on systems
with only a few cores. So, instead, allocate 4 messages per CPU
(though often more, due to rounding up to the page size; e.g.
on x86_64, 1 page fits 56 smp_msgs.)
Also, put them a dedicated area, to keep them a bit more segmented
from the kernel heap, in case of problems.
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 read spinlocks to be used in check_for_message
and return_free_message.
On a 4-core VM, there don't seem to often be concurrent readers
(a counter I setup got only about 400-500 hits for booting up
and starting a web browser, at most.) But on bare metal (i3,
2 cores x 2 hyperthreads) we get it a lot more: 30,000+ times
during boot alone.
Kernel map invalidation (with a hack to invalidate all every time)
across boot-to-desktop takes a cumulative ~68.0ms before this change,
and ~61.0ms after, on the bare metal system. (On the VM it's also lower
after this change.)
Presumably on systems with more CPUs it will get hit even more
often still. So this optimization seems worth it.
They call out to other library functions, which are better optimized
than the old naive implementations.
Add -fno-builtin to the musl strings Jamfile, otherwise GCC
generates infinite recursion in strcpy, apparently.
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.
This adds a new job to the Package Kit, and an invocation
in pkgman after changes are applied. The job takes a time_t before,
and an int32 minToKeep, and (after confirmation) deletes all state
directories which were last modified before that time, but also
keeps at least the minimum specified.
pkgman defaults to calling it with (now - 30 days, minimum 10).
SoftwareUpdater does the same, but without bothering the user
and just defaults to doing the cleanup.
Change-Id: I15f5232b11daba5955e7fa07f696ad7785507931
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10404
Reviewed-by: waddlesplash <[email protected]>
It doesn't refer to some random old state, but the currently active
one. (If the currently active state is the default one, then it will
return nothing.) So, this should make things clearer.
Change-Id: Ib3fe842f5fb51eaf2ef2f31bad8b292b47a3fb36
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10403
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This header gets included in the build platform, so we can't use
the private recursive_lock.
Eliminates another statically created BLocker, due to gDefaultTokens.
This is not an expected failure condition for most applications,
so try to avoid propagating it to userspace.
(If necessary, it should be possible to avoid even the possibility
of this by just allocating necessary datastructures upfront
instead of "lazily". But that seems unnecessary at the moment.)
The lighter "struct mutex" is in a private header, so we can't
inline it in a public one, so just use pthread_mutex here.
By adjusting padding, the class size stays the same (72 bytes
on 32-bit, 96 bytes on 64-bit; confirmed via static_assert.)
A quick benchmark running "new/delete BMessage" in a loop on 4
threads at once goes from 30-36 seconds before this commit
to around 13-17 seconds, sometimes as low as 3 seconds, afterwards,
so clearly this is a significant improvement.
This also eliminates another BLocker allocated on application startup.
It seems in some applications (though not most of the ones I
initially tested) this can get used recursively, so we need
a recursive_lock in order to not deadlock.
Also commit a missed change from the previous commit.
X512 pointed out that ServerLink is inherited by PortLink which is
used by all windows, so the original change had the unintended effect
of allocating another semaphore for every window, which isn't wanted.
So, just use a static mutex here also.
The case where no BApplication has been created at the time of fork
is not blocked by this change (as it might be useful in fork-to-background
before creating a BApplication.)
Reinitializing or recreating a BApplication where one already exists,
though, is not supported by the kits, and just leads to problems.
And when the global destructors are invoked after a fork, such as by
exit(), then the parent team's state may be corrupted due to the
deletion of BLocker semaphores or other global state.
So, we thus set be_app to an invalid pointer, and if terminate_after()
is called with this pointer, we invoke debugger().
(We should really just prevent semaphores from being used across
processes unless explicitly specified, but that would be an
API compatibility break from BeOS, so we'll need to do it carefully,
or not until after R1.)
Would have clearly caught the problem in #18576 and the linked thread.
They don't work properly after a fork, and if exit() is called
from the forked child, the parent won't be able to use them
anymore.
In BBitmap and BPicture, replace them with mutexes. For AppServerLink,
make the private ServerLink inherit from BLocker, and then use
that one directly.
This also is a slight efficiency gain, as we don't need to create
multiple semaphores from the static initializers now, which is
just a waste of time in the case of applications that don't
even need these locks but link to libbe.so (e.g. CLI tools.)
Part of #18576.
This now does what notify_if_stat_changed used to, fixing a
race: if some thread was modifying a file, and some other thread
(or the same thread, in some other mtime-updating operation)
updated that file and this called MarkUnmodified() before the
first thread close()d it, then when the first thread called close(),
no node monitor notification would've been sent, as fModified
would've already been unset.
So, now every time we are to mark a file "unmodified", we also
send the node monitor notification at the same time.
Fixes the remainder of #19910.
This reverts commit 902921a554.
This broke resolution of CNAMEs, including the Haiku package repos.
Since pkgman uses our own HTTP implementation, which doesn't set
AI_V4MAPPED at all, this shouldn't have been a behavioral change for
it at all, much less having broken it.
Change-Id: If38b6a81c1144101ddea7d1f8d401326675479e3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10388
Reviewed-by: waddlesplash <[email protected]>
If a context switch happened between the messsage being
sent and received, we don't need to invalidate.
Brief testing on a 4-core VM shows this happens relatively
rarely during compile jobs (expected, most processes are
single-threaded), but very often while running multiprocess
web browsers. Some INVALIDATE_PAGES are skipped, but mostly
INVALIDATE_PAGE_LIST is (by the thousands.)
Change-Id: If32ed95139e0db3770054f6ef3f72c9aecb9394d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10350
Reviewed-by: waddlesplash <[email protected]>
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]>
This way we don't need to call barrier_unlock() in every thread
after exiting the wait loop, some syscalls. We can also avoid
spinning on the barrier mutex in "ensure_idle" (which is renamed
"ensure_none_exiting" for clarity), and instead lock it once and wait
for some thread to unblock all.
Overall, this strategy appears to be as much as 25% faster
than the previous, testing with pthread_barrier_test.
It seems the old design had at least one possible but very narrow
race in the "last one out" logic: if that thread was suspended
between the atomic_add() and the assignment of barrier->lock, and
all three other threads then ran past the add() in the next run,
then when the last-one-out woke up, it would clear the WAITING
flag spuriously.
This may help with #19876.
If we have no allocated swap space, then we don't need to even
bother doing a lookup in the hash table (which requires a read-lock,
anyway.)
This function is now called often even if swap isn't actively
being used, so any gains here are helpful.
waddlesplash