So that it has the same naming as DoublyLinkedList.
No functional change. It seems there aren't any users
of this API in the default build at the moment.
* This is the closest thing ARM has the semantics of write-combining
MTR on x86.
Change-Id: I12a1582e0af871e2ab729262e90695ffe928c85b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8223
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Implemented using __builtin_clz where available, otherwise using
an algorithm derived from "Bit Twiddling Hacks" which is similar
to the one ramfs uses. GCC and Clang seem to unroll the loop on
x86 at least (but it doesn't matter there as the builtin exists,
implemented using the "bsr" instruction.)
These are architecture-specific routines, so they deserve proper
architecture-specific naming. The user memory access routines are
already under arch_cpu (arch_cpu_user_memcpy, etc.), and the methods
usually change a CPU flag, so it makes sense to put these there too.
RISC-V had get_ac but nothing else defined or used it, so it's removed.
No functional change intended.
Change-Id: Id4715214e32f73d4a93bc7ba8249411a0878d174
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8106
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
So we need to check that it didn't when creating areas.
Change-Id: I4342463113046b543722faa7a51ca269ed67e8bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8137
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
According to the ARMv7 Reference Manual, "Wait for Interrupt" is supported only through the WFI instruction on ARMv7.
The currently used ARMv6 equivalent may not work on ARMv7 and newer CPUs.
Fixes #18520
Change-Id: I69a136870654be33c0c789004e08bf610db3dd97
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8044
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
ramfs needs to create caches that are both temporary and unmergeable,
so add another flag to make this state possible.
Otherwise, mmap'ed files from ramfs might wind up in VMCache
trying to merge the caches when the last one is closed, which
we don't want.
The IORequest internally likes to deal with transferEndOffset
not transferredBytes because of sub-requests potentially being
prepared all at once (in some paths in the I/O scheduler),
thus fTransferSize can get incremented in Advance() before we have
actually executed that transfer.
But external consumers much prefer just knowing transferredBytes
not transferEndOffset. And many of them actually named their
variables that (or "bytesTransferred") and just passed the
transferEndOffset through to variables with that name! That's
obviously wrong, and it's surprising it wasn't discovered before now.
The problem was uncovered by repeated KDLs in PrecacheIO.
That method used the "bytesTransferred" value as a count of
pages transferred, which would then run past the end of the array
if the transfer start offset was not 0 (which the majority
of the time it would be, since this method gets called on
the first mmap() of a file, probably before any pages are read in.)
Most other consumers of this API did not check the value, it seems,
or otherwise had some mitigating factor that prevented it from
causing more problems. An exception is the page code, which
may have spuriously considered writes as successful when they
really weren't.
May fix some of the "invalid concurrent access to page" KDLs.
Every time a page is mapped into an area on fault, we have to
allocate a mapping object for it. While the object_cache
does have per-CPU depots, these depots only store a limited
number of items, and once they run out the object_cache's lock
must be acquired.
So, to reduce lock contention on SMP systems, create a number
of object caches corresponding to the nearest power of 2
that is equal or smaller than the count of CPUs. (We already
allocate dozens of object caches for the block allocator
no matter how many CPUs there are, so a few more depending
on CPU count shouldn't impact memory use too much. Besides,
the object_caches are wired into the low_resource system.)
This significantly reduces lock contention on SMP systems.
Same benchmark setup as yesterday (compile mime_db and relink
HaikuDepot, VMware, -j4), before:
real 0m16.981s
user 0m14.357s
sys 0m6.060s
after:
real 0m14.522s
user 0m14.194s
sys 0m4.337s
And the page_mappings object_cache locks went from having 200,000+ waits
and ~14 seconds waiting time (across all threads) down to ~900 (yes,
that's not a typo) and ~0.05s wait time (though these numbers were captured
in conjunction with the following commit.)
* Put close/free at the beginning since all FDs must implement that.
(Most of the function declarations inline were already in this order.)
* Add readv/writev hooks. Not used yet, but this will allow for
more than just files to implement them. All declarations updated
to have NULL for the hooks for the moment.
It allows introducing new file descriptor types without editing enumeration every time. Anonymous FDs will be needed for Mesa
OpenGL/Vulkan drivers to reference GPU memory buffers and other driver objects that can be referenced as FDs from userland.
This change breaks private VFS API compatibility.
No behavior changes intended.
Change-Id: Iac109aad420b0b6aae704b38619436e01dcf4969
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7838
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Instead of taking the sample inside the timer callback
or the flush callback depending, always take it in the timer
callback, for consistency's sake. This should always work
because we try to flush the buffer when it's only 70% full;
in testing I can't recall seeing any dropped ticks.
Also add a flush call in the post_syscall hook, in case
we hit the flush threshhold while profiling in the kernel
and couldn't trigger the flush then.
Seems to significantly reduce "missed" ticks overall,
but there are still wildly inconsistent results and
lots of missing time.
Change-Id: I43a5e9c050a50309329da39f8a2386c3e2b3c0dd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7851
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The "-k" argument (which never did anything before) is now inverted
compared to what it used to be, i.e. now specifying it will profile
kernel frames, too, whereas by default only user frames will be
sampled.
Adds a `signal` field to the `team_deleted` event. Since killing
signals like `SIGKILL` and `SIGKILLTHR` do not generate a
`signal_received` event, debuggers would only see a `team_deleted`
message with the `status` field set to 0. This makes debuggers like
GDB think that the debuggee has exited with a status code of 0.
To correctly report these signals, when a killing signal is sent
to a team, this signal is relayed to the main thread instead of
defaulting to just a `SIGKILLTHR` for both cases.
Change-Id: If69c9e2e4d87bfbd31f654f5cb6f696ac69ef777
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7756
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
scheduler modes adapted to take into account the thread affinity mask.
when no cpu in the affinity mask is enabled, the mask is ignored.
Change-Id: I577737441ab073941a4c5e06f94f7825cffdc2c4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7674
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Add a field to `debug_[team/thread]_deleted` to report the exit status
on the corresponding events.
This is useful for debuggers like GDB expecting a return value when one
of their inferiors quit.
Also add a `usage` field to `debug_team_deleted` since this is another
potentially useful piece of information exposed by the `waitpid` family
of syscalls.
Change-Id: Ieff7c31f56b1b9f8f709725d19050273b21f2504
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7736
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It's not used for anything by the OS but userspace might want
to use it for its own purposes.
Change-Id: Icda4bcd6de9d68596555e81293c8bd075f80a2a4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7511
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is no-op for 32 bit platforms because `int32` is defined as `long` there.
Change interrupt vector number from 64 bits to 32 bits for 64 bit platforms.
Change-Id: I52d1ad616cab16488804e9733c7afaf772a670ba
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7507
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Also increase MSI message data size to 32 bits according to PCIe spec.
Remove 0xff check for MSI interrupts because it is potentially valid
interrupt vector number. Reject 0xff only for legacy pin interrupts.
- MSI-X supports up to 2048 interrupts per device that do not fit to
`uint8`.
- Non-x86 systems may use separate interrupt vector ranges for
hard-wired interrupts and MSI interrupts so `uint8` is not enough to
represent all of them.
Change-Id: Iaf9ffb197ec23db0f97ffe3ea756d28d7bfc8705
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7433
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
after a0131eaae2884fdced27158c3d34732d1656aca9 mxcsr was possibly also incorrect.
fpu control and mxcsr will be restored with fxrstor/xrstor.
no need to clear pending exceptions on #MF
fix #18656 (and #18624 after reverting).
Change-Id: I7dd5e2e4610747c5b82abd6c67e302d264b4be92
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7104
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* also on x86 for simplicity.
* fixes #18624
* also makes x87 FPU data registers available for x87 floating instructions. EMMS is cheap.
see 25209d81f7
Change-Id: I5c1b399377102f3eb10bc6d7f7247afbaf6d8483
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7089
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
While debugging some problems on the HaikuPorts build VMs, mmlr
noticed their clocks had an alarming amount of drift. This prompted
an investigation into TSC calibration mechanisms, and the discovery
that there is a VM-specific one which we did not implement.
This mechanism is more accurate than counting cycles on VMs where
cycles can be "stolen" (the probable cause of the aforementioned
clock drift.)
Tested in VMware (works out of the box) and on QEMU/KVM
(may need TSC frequency specified or a host with invariant TSC.)
Change-Id: I4ccfdb2e4e2621404ec9026e7106c02bf96faf18
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7063
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This undoes fc7864091e2463c0e446f8b3954df4d29e9465af.
It was only ever used by the FreeBSD compatibility layer,
only supported one structure, and created problems with
concurrent builds.
Only the x86 and PPC implementations look like they would have worked,
while the builtin is available and will work across all architectures.
We already use it unconditionally in some parts of libroot.
Change-Id: I2dffb3b2c7cdd605092382b9d649151adb921bb4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6942
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
on x86_64 implemented with rdtscp or rdpid, generically with a syscall.
Change-Id: I8f776848bf35575abec8a8c612c4a25d8550daea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6866
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Implemented `UnixBufferQueue::SetCapacity` so that `setsockopt`
with `SO_RCVBUF` will not always return an error.
Change-Id: I2d9be84633f84474fac64b379e9f89ef2751a094
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6816
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
