summaryrefslogtreecommitdiffstats
path: root/arch/sparc
diff options
context:
space:
mode:
authorJavier González <jg@lightnvm.io>2017-06-26 11:57:27 +0200
committerJens Axboe <axboe@kernel.dk>2017-06-26 16:27:39 -0600
commitb20ba1bc749ce0cd7a74d24f23826a6462c3de53 (patch)
tree4a28d3558c007f5e7d27d4e24b7ed37723a16609 /arch/sparc
parent476118c981f0fd909cd95a1732073120c6806ac0 (diff)
downloadlinux-b20ba1bc749ce0cd7a74d24f23826a6462c3de53.tar.gz
linux-b20ba1bc749ce0cd7a74d24f23826a6462c3de53.tar.bz2
linux-b20ba1bc749ce0cd7a74d24f23826a6462c3de53.zip
lightnvm: pblk: redesign GC algorithm
At the moment, in order to get enough read parallelism, we have recycled several lines at the same time. This approach has proven not to work well when reaching capacity, since we end up mixing valid data from all lines, thus not maintaining a sustainable free/recycled line ratio. The new design, relies on a two level workqueue mechanism. In the first level, we read the metadata for a number of lines based on the GC list they reside on (this is governed by the number of valid sectors in each line). In the second level, we recycle a single line at a time. Here, we issue reads in parallel, while a single GC write thread places data in the write buffer. This design allows to (i) only move data from one line at a time, thus maintaining a sane free/recycled ration and (ii) maintain the GC writer busy with recycled data. Signed-off-by: Javier González <javier@cnexlabs.com> Signed-off-by: Matias Bjørling <matias@cnexlabs.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'arch/sparc')
0 files changed, 0 insertions, 0 deletions