Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backfill optimization #834

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

mmichal10
Copy link
Contributor

No description provided.

@mmichal10 mmichal10 force-pushed the backfill-optimization branch 2 times, most recently from 53c508a to 1972ee1 Compare September 23, 2024 05:12
Deixx
Deixx previously approved these changes Sep 23, 2024
SaraMerzel and others added 3 commits September 23, 2024 12:34
A new status for cache lines that are partial hits

Signed-off-by: Sara Merzel <sara.merzel@huawei.com>
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Simplify calculating addr and size.

Getting rid of a few ifs shouldn't impair the performance as well!

Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Copy link
Contributor

@rafalste rafalste left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems OK. My only consideration is, if it wouldn't be better to use the existing implementation of ocf_engine_forward_cache_io_req() and just add the conditional if (req->map[i].status == LOOKUP_HIT) to it (as a flag maybe), instead of copying over the whole function content.

@mmichal10
Copy link
Contributor Author

@rafalste I think the implementation is too specific for backfill to apply it in a generic function like ocf_engine_forward_cache_io_req(). The hits couldn't be skipped for read requests so it would generate another special case to handle. Also, the optimizatized code doesn't actually skip all hits; it skips a hit only if it's not preceded by an adjacent miss (it's to avoid sending too many small requests to cache if the cachelines are hits and misses in turn)

Comment on lines +74 to +77
#define __is_the_last_chunk(__req, __i) (__i == (__req->core_line_count - 1))

#define __skip_on_the_last_entry(__skip, __req, __i) \
__skip * (int)__is_the_last_chunk(__req, __i)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's no longer 90's, unlikely() should do.

Comment on lines +110 to +111
last_chunk_size = (req->addr + req->bytes) % cache_line_size;
skip = (cache_line_size - last_chunk_size) % cache_line_size;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This math is very confusing. The last_chunk_size is not really last chunk size, because it can be 0 if last chunk is aligned to cache line size, and then to account for that, the skip is "corrected" with this surprising modulo.

total_bytes -= seek;
/* Seek should be taken into account for the first chunk
only */
seek = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer unlikely() on if (i == 0). Now we are zeroing this seek here and there many times for completely no reason.

Comment on lines +138 to +139
addr += seek;
bytes -= seek;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here we completely unnecessarily add/subtract 0 on every loop iteration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants