This helps ensure no one accidentally accesses m_requests without first
locking it's spinlock. In fact this change fixed such a case, since
process_cq() implicitly assumed the caller locked the lock, which was
not the case for NVMePollQueue::submit_sqe().
Instead of assuming data races won't occur and trying to somehow verify
it with manual un-atomic tracking, we can just use a recursive spinlock
instead of a normal one, to resolve the original deadlock.
Most of the actual logic is identical, with the only real difference
being that one wraps it with an async work item.
Merge the implementations to reduce duplications (which will also
require the fixes in the next commits to only be done once).
Shadow doorbell feature was added in the NVMe spec to improve
the performance of virtual devices.
Typically, ringing a doorbell involves writing to an MMIO register in
QEMU, which can be expensive as there will be a trap for the VM.
Shadow doorbell mechanism was added for the VM to communicate with the
OS when it needs to do an MMIO write, thereby avoiding it when it is
not necessary.
There is no performance improvement with this support in Serenity
at the moment because of the block layer constraint of not batching
multiple IOs. Once the command batching support is added to the block
layer, shadow doorbell support can improve performance by avoiding many
MMIO writes.
Default to old MMIO mechanism if shadow doorbell is not supported.
Introduce a new Struct Doorbell that encapsulates the mmio doorbell
register.
This commit does not introduce any functional changes and it is added
in preparation to adding shadow doorbell support.
This was the root cause of zombie processes showing up randomly and
disappearing after some disk activity, such as running shell commands -
The NVMeIO AsyncBlockDeviceRequest member simply held a pointer to a
Process object, therefore it could keep it alive a for a long time after
it ceased to actually function at all.
The Storage subsystem, like the Audio and HID subsystems, exposes Unix
device files (for example, in the /dev directory). To ensure consistency
across the repository, we should make the Storage subsystem to reside in
the Kernel/Devices directory like the two other mentioned subsystems.
2023-06-02 11:04:37 +02:00
Renamed from Kernel/Storage/NVMe/NVMeQueue.h (Browse further)
