The cleaning metadata has been deinitialized in the previous pipeline
step together with other services
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Unfreezing a refcnt might be a sleeping operation so it can't be called
from completion context. Moving D2C refcnt unfreeze to a separate step
in pipeline ensures that it will always be called from process context
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
The cleaning metadata has been deinitialized in the previous pipeline step
together with other services
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Flushing metadata has nothing to do with dinitializing services so it
should be a separate step in the stop pipeline
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Move flushing metadata outside cache_detinit_services(), so the function
can be shared between stop() and detach() without redundant ifs.
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
The completion callback is called only in the cache stop scenario, after
flushing the metadata
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
During core remove/detach ocf_cleaner_refcnt_freeze was called only
when cache was attached, but ocf_cleaner_refcnt_unfreeze was called
regardless of cache state.
Signed-off-by: Daniel Madej <daniel.madej@huawei.com>
After attaching new cache device handle all the IOs in Pass-Through mode
until all the d2c requests are completed.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
New caches are added to the list at the point where they are already
initialized and no errors are possible at this point, hence list_del() in error
handling is redundant.
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 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>
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>
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>
