You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 8, 2024. It is now read-only.
I'm PhD student and doing research based on EnhanceIO.
I heard that EIO is forked from flash-cache.
So, I compare two SSD-caches.
For evaluation, I ran same benchmark (fio) on EIO and Facebook's flash-cache.
With EXT4 (ordered journaling), flash-cache shows much better performance than EIO. (measured bandwidths are 40,891 KiB/s (flash-cache) and 23,988 KiB/s (EIO) each)
I think rw-lock of each cache_sets makes this performance gap.
Since journaled write is sequential write, it dirties several specific cache_sets easily.
It means that, they are much likely to be cleaned by write-back thread than other cache_sets.
More seriously, because it is synchronous write, if journaled write is blocked, it hurts application's performance significantly.
My question is why EIO protects each set by rw-lock.
In terms of memory size of cache metadata, EIO got a significant benefit.
However, I think, because EIO takes course-grained lock for protecting cache_set and its on-flash metadata, it can hurt its performance.
Is this just for memory size issue?
Or, did I miss some important details in design or implementation?
Thanks.
-Sung-hun
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm PhD student and doing research based on EnhanceIO.
I heard that EIO is forked from flash-cache.
So, I compare two SSD-caches.
For evaluation, I ran same benchmark (fio) on EIO and Facebook's flash-cache.
With EXT4 (ordered journaling), flash-cache shows much better performance than EIO. (measured bandwidths are 40,891 KiB/s (flash-cache) and 23,988 KiB/s (EIO) each)
I think rw-lock of each cache_sets makes this performance gap.
Since journaled write is sequential write, it dirties several specific cache_sets easily.
It means that, they are much likely to be cleaned by write-back thread than other cache_sets.
More seriously, because it is synchronous write, if journaled write is blocked, it hurts application's performance significantly.
My question is why EIO protects each set by rw-lock.
In terms of memory size of cache metadata, EIO got a significant benefit.
However, I think, because EIO takes course-grained lock for protecting cache_set and its on-flash metadata, it can hurt its performance.
Is this just for memory size issue?
Or, did I miss some important details in design or implementation?
Thanks.
-Sung-hun
The text was updated successfully, but these errors were encountered: