-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
zio performance #3063
zio performance #3063
Conversation
Long ago the zio_bulk_flags module parameter was introduced to facilitate debugging and profiling the zio_buf_caches. Today this code works well and there's no compelling reason to keep this functionality. In fact it's preferable to revert this so the code is more consistent with out ZFS implementations. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
The zio_cons() constructor and zio_dest() destructor don't exist in the upstream Illumos code. They were introduced as a workaround to avoid issue openzfs#2523. Since this issue has now been resolved this code is being reverted to bring ZoL back in sync with Illumos. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
c3be2b5
to
cd4f20e
Compare
EDIT: nevermind, apparently i needed to rebase the patch stack from master - something was a forced push i guess. Apologies, will test more thoroughly... |
@sempervictus This used to be based on the large block patches but I recently rebased it on master because they're clearly unrelated changes. |
Just looked over basic benchmarks from my own host from ~10 months ago, and the write improvement is significant. 0.6.2 with some patches, including scatter/gather ARC buffers. Note the read speed, and the CPU ticks required for that (this is a 10 core xeon):
This is today with this stack applied:
Linear and random reads appear to be bound somewhere, probably in ARC reads (no SG patch applied). Random writes may well have suffered from the pool going from 15% to 65% capacity and 49% fragmentation. Whatever the case, and however many factors in the basic benchmark, with LZ4 enabled, it wrote 1.6G in about 2s, which is what makes happy users. |
nice ! mark the significant increase of "Sys CPU" for Read and Random Read, might be due to fuller pool, but perhaps still something to look into so the up-to-date results is without "scatter/gather ARC buffers" ( #2129 ) if I understood correctly ? |
@kernelOfTruth: Yes, #2129 (ABD) was in use during the initial test. @ryao has mentioned work on scatter/gather buffers which dont require the data be copied between different structures, with potentially wider application than ARC alone. |
@sempervictus There have been a lot of changes between 0.6.2 and here but it's good to see that things are moving in the right direction. I'm personally optimistic that the recent ARC performance work done for Illumos and the ABD+SG changes should help with those read numbers. |
Long ago the zio_bulk_flags module parameter was introduced to facilitate debugging and profiling the zio_buf_caches. Today this code works well and there's no compelling reason to keep this functionality. In fact it's preferable to revert this so the code is more consistent with other ZFS implementations. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Ned Bass <bass6@llnl.gov> Issue openzfs#3063
The zio_cons() constructor and zio_dest() destructor don't exist in the upstream Illumos code. They were introduced as a workaround to avoid issue openzfs#2523. Since this issue has now been resolved this code is being reverted to bring ZoL back in sync with Illumos. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Ned Bass <bass6@llnl.gov> Issue openzfs#3063
Long ago the zio_bulk_flags module parameter was introduced to facilitate debugging and profiling the zio_buf_caches. Today this code works well and there's no compelling reason to keep this functionality. In fact it's preferable to revert this so the code is more consistent with other ZFS implementations. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Ned Bass <bass6@llnl.gov> Issue openzfs#3063
Long ago the zio_bulk_flags module parameter was introduced to facilitate debugging and profiling the zio_buf_caches. Today this code works well and there's no compelling reason to keep this functionality. In fact it's preferable to revert this so the code is more consistent with other ZFS implementations. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Ned Bass <bass6@llnl.gov> Issue openzfs#3063
Two patches designed to bring ZoL's zio create/destroy code back in sync with Illumos/FreeBSD. They also act as a starting point for further optimization. Profiling clearly shows that a considerable amount of time is being spent in
zio_create()
which can limit throughput on high-end systems.This profiling also revealed significant contention in
spa_dispatch_ent()
during a heavy write workload. One possible fix for this is to increase the number of write taskqs to reduce the contention, and a patch is provided which does this. However, other possible solutions should be explored.NOTE: These changes are based on the currently unmerged large block feature branch.