The fewer (atomic variable accesses on IO path) the better fare
Signed-off-by: Roel Apfelbaum <roel.apfelbaum@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
UBSAN: array-index-out-of-bounds in src/ocf_request.c:230:44
index 1 is out of range for type 'ocf_map_info [*]'
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
`req->error` should be modified by the request's owner only; hence, if
the request has been allocated to handle IO (i.e. it's not an internal OCF
request) only engines can change it
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
When IO queues are used for parallelized management operations,
e.g. changing cleaning policy, a deadlock may occur due to global
metadata lock interfering with taking request from IO queue,
as they might be run on the same thread. As a workaround using
a management queue specifically for such operations eliminates
this problem.
Signed-off-by: Rafal Stefanowski <rafal.stefanowski@huawei.com>
This one is quite special, because it can be called before cache is
instantiated, which means we can not allocate the request using
ocf_req_new_mngt() due to absence of mngt_queue. For that reason we
simply allocate request using env_zalloc() and then release it with
env_free(). The lifecycle of the request is very straightforward and
the only used fields are forward counter and callback.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
It's intended to be used in a context, where cache is not initialized
and the io_queue is not available yet.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
struct ocf_io is going to be removed soon (consolidated with ocf_request).
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Skip the ocf_io abstraction and get the data directly from the request.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Those are meant to be used in context where no cache nor queue is
available (typically at very early stage of initialization). We reuse
cache_forward* callback and counter, because they will not be used
in this context anyway.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
This is meant to be used in atomic mode to avoid allocating huge buffers
for zeroing data on drive.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Avoid unnecessary code execution in D2C mode.
Avoid multiple req->d2c check in normal I/O path.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Allow composite volume to forward the io to sub-volumes, splitting it
into several forward operations when needed. This is still done with
zero allocations, making forward even more efficient when combined with
composite volume.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Allow the core volume IOs to be forwarded directly to backend volumes to
avoid unnecessary allocations.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Signed-off-by: Avi Halaf <avi.halaf@huawei.com>
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
This avoids unnecessary map allocation and initialization of unused fields of
request structure. It also allows to track thier number separately from
the regular requests
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Eliminate need to resolve cache based on the queue. This allows to share
the queue between cache instances. The queue still holds pointer to
a cache that owns the queue, but no management or io path relies on the
queue -> cache mapping.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Management path does not benefit much from mpools, as number of requests
allocated is very small. It's less restrictive (mngt_queue does not have
single-CPU affinity) thus avoiding mpool usage in management path allows
to introduce additional restrictions on mpool, leading to I/O performance
improvement.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
The user is supposed to deinit/destroy it.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
In situation when all the shards finish their work before parallelize
loop does it's final loop condition check, which involves access to
parallelize object, it's possible that parallelize object will be
deinitialized before this final access.
Increasing refcount by 1 before running parallelize and decreasing it
only after the loop is finished addresses this problem.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
In some scenarios running the exact number of shards, regardless of
number of available queues is crucial for correctness of operation.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Otherwise, it may increase the number of hits, while the overall performance
has not been improved. This way, the hit rate is more correlated with
the performance changes.
Signed-off-by: Michael Lyulko <michael.lyulko@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
The queues can be created and destroyed dynamically at any point in
the cache lifetime, and this can happen from different execution contexts,
thus there is a need to protect the queue_list with a lock.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Previously every created queue was added to io_queues list, which
made mngt_queue being used in ocf_parallelize. Change mngt_queue creation
API so that mngt_queue is not added to the list and doesn't have
unnecessary functionalities initialized.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
The completion function should be the same either when it is called from
the queue context or from currnet context
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Commit db6b009ef introduced changes in managing the master request life cycle,
but apparently not all paths have been updated. This change removes a redundant
ocf_req_get() before sending the requets into a queue
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
When flushing a request, the number of cache reads is unknown until all cache
lines are locked and the IOs are actually submitted.
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Now the request can be pushed to a high priority queue (instead of ocf_queue_push_req_front)
and to a low priority queue (instead of ocf_queue_push_req_back).
Both functions were merged into one function (ocf_queue_push_req) and instead of the
allow_sync parameter there is now a flags parameter that can be an OR combination of
OCF_QUEUE_ALLOW_SYNC and OCF_QUEUE_PRIO_HIGH
Signed-off-by: Ian Levine <ian.levine@huawei.com>
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
This functionality is used by cleaning policies via cmpl_queue
to reschedule the completion, so that we avoid unlocking mutex in
the cleaner completion from interrupt context of IO completion.
This reverts commit 1e5eda68a7.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
The flush_data is used by ocf_cleaner_do_flush_data_async(), which means
that callers of ocf_cleaner_fire() are now expected to guarantee that
entries are returned by getter in a sorted order. Currently the only case
when ocf_cleaner_fire() is called directly is for request cleaning, and
the request map is sorted by definition.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Majority of management operations should be blocked for detached cache,
although adding and removing cores should be possible.
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
