Searched hist:bba681cbb231920a786cd7303462fb2632af6f36 (Results 1 – 4 of 4) sorted by relevance
| /openbmc/linux/Documentation/ABI/testing/ |
| H A D | sysfs-fs-f2fs | diff bba681cbb231920a786cd7303462fb2632af6f36 Mon Jan 26 19:41:23 CST 2015 Jaegeuk Kim <jaegeuk@kernel.org> f2fs: introduce a batched trim
This patch introduces a batched trimming feature, which submits split discard
commands.
This is to avoid long latency due to huge trim commands.
If fstrim was triggered ranging from 0 to the end of device, we should lock
all the checkpoint-related mutexes, resulting in very long latency.
Reviewed-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
|
| /openbmc/linux/fs/f2fs/ |
| H A D | segment.c | diff bba681cbb231920a786cd7303462fb2632af6f36 Mon Jan 26 19:41:23 CST 2015 Jaegeuk Kim <jaegeuk@kernel.org> f2fs: introduce a batched trim
This patch introduces a batched trimming feature, which submits split discard
commands.
This is to avoid long latency due to huge trim commands.
If fstrim was triggered ranging from 0 to the end of device, we should lock
all the checkpoint-related mutexes, resulting in very long latency.
Reviewed-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
|
| H A D | super.c | diff bba681cbb231920a786cd7303462fb2632af6f36 Mon Jan 26 19:41:23 CST 2015 Jaegeuk Kim <jaegeuk@kernel.org> f2fs: introduce a batched trim
This patch introduces a batched trimming feature, which submits split discard
commands.
This is to avoid long latency due to huge trim commands.
If fstrim was triggered ranging from 0 to the end of device, we should lock
all the checkpoint-related mutexes, resulting in very long latency.
Reviewed-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
|
| H A D | f2fs.h | diff bba681cbb231920a786cd7303462fb2632af6f36 Mon Jan 26 19:41:23 CST 2015 Jaegeuk Kim <jaegeuk@kernel.org> f2fs: introduce a batched trim
This patch introduces a batched trimming feature, which submits split discard
commands.
This is to avoid long latency due to huge trim commands.
If fstrim was triggered ranging from 0 to the end of device, we should lock
all the checkpoint-related mutexes, resulting in very long latency.
Reviewed-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
|