ACP Cleaning Policy for Chunk with small dirty cache lines about ocf HOT 4 CLOSED

Not sure whether we need to update function cleaning_policy_acp_perform_cleaning to make it real flush "-b" dirty cache blocks no matter how much dirty blocks are in one chunk.

from ocf.

I think that the real error here is just wording in CLI. Maybe it should be something like **Maximum** number of dirty cache blocks to be flushed in one cleaning cycle?

As for ACP policy flushing -b dirty blocks per iteration I that that was not the behavior we were going for. Any comments on that @arutk ?

from ocf.

I believe the original intention was to have ACP clean exactly "-b" dirty cache lines. I agree with John's analysis - ACP will issue smaller I/O at the end of chunk.

So it looks like implementation shortcoming. Possible fix would involve:

1. modifying acp_perform_cleaning() to issue second flush I/O if the first call had not reached the requested flush package size.
   We probably shouldn't iterate over more than two chunks in a single iteration, since this means that the cache is basically clean and cleaner performance is not relevant at this point.
2. _acp_prepare_flush_data() and _acp_flush() would accept offset parameter to indicate start position in in state->flush array.
3. Modify _acp_flush_end() to wait for the second I/O before calling upper layer completion callback.

from ocf.

This doesn't seem to be a noticeable problem, as ACP by design cleans the chunks that are most dirty. Assuming there is some workload LBA locality (which is a reasonable assumption for cache), the core LBA range (chunk) being cleaned has relatively large number of dirty cachelines. So one would need to set very large flush portion to make this problem noticable (i.e. measure reduced cleaner bandwidth).

We haven't heard from any user hitting this problem in real life scenarios, so closing this .

from ocf.