Great to see fs_locks is to be replaced. :)
There is a potential problem with using r/w semaphore this way. The
thread doing checkpoint might get starved if other threads are
intensively locking the read semaphore for I/O. I noticed that Josef
introduced a rwsem_is_contended for solving similar i
Did this patch pass the basic build? There seems have a typo
regarding MAX_BIO_BLOCK.
--
Jin
On 13/09/2013 18:07, Chao Yu wrote:
> This patch add macro MAX_BIO_BLOCKS to limit value of npages in
> f2fs_bio_alloc,
> it can avoid to return NULL in bio_alloc caused by npages is larger than
> UIO_MAX
function call
overhead
- reduce multiplication and division operations
- reduce unnecessary comparison operation
Signed-off-by: Jin Xu
---
fs/f2fs/gc.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index a78b8e3..14187bf
Hi,
On 11/09/2013 21:19, Kim Jaegeuk wrote:
Hi Russ,
The usage of fs_locks is for the recovery, so it doesn't matter
with stress-testing.
Actually what I've concerned is that we should not grab two or
more fs_locks in the same call path.
Thanks,
I am wondering why we don't use other kind of
From: Jin Xu
This patch improves the gc efficiency by optimizing the victim
selection policy. With this optimization, the random re-write
performance could increase up to 20%.
For f2fs, when disk is in shortage of free spaces, gc will selects
dirty segments and moves valid blocks around for
Yes, I will submit the patch later.
On 05/09/2013 07:50, Jaegeuk Kim wrote:
Hi Jin,
2013-09-04 (수), 21:17 +0800, Jin Xu:
Hi Jaegeuk,
On 04/09/2013 17:40, Jaegeuk Kim wrote:
Hi Jin,
2013-09-04 (수), 07:59 +0800, Jin Xu:
Hi Jaegeuk,
On 03/09/2013 08:45, Jaegeuk Kim wrote:
Hi Jin
Hi Jaegeuk,
On 04/09/2013 17:40, Jaegeuk Kim wrote:
Hi Jin,
2013-09-04 (수), 07:59 +0800, Jin Xu:
Hi Jaegeuk,
On 03/09/2013 08:45, Jaegeuk Kim wrote:
Hi Jin,
[...]
It seems that we can obtain the performance gain just by setting the
MAX_VICTIM_SEARCH to 4096, for example.
So, how about
Hi Jaegeuk,
On 03/09/2013 08:45, Jaegeuk Kim wrote:
Hi Jin,
[...]
It seems that we can obtain the performance gain just by setting the
MAX_VICTIM_SEARCH to 4096, for example.
So, how about just adding an ending criteria like below?
I agree that we could get the performance improvement by
Hi Jaegeuk,
On 08/29/2013 07:56 PM, Jaegeuk Kim wrote:
Hi,
2013-08-29 (목), 08:48 +0800, Jin Xu:
From: Jin Xu
This patch improves the foreground gc efficiency by optimizing the
victim selection policy. With this optimization, the random re-write
performance could increase up to 20
From: Jin Xu
This patch improves the foreground gc efficiency by optimizing the
victim selection policy. With this optimization, the random re-write
performance could increase up to 20%.
For f2fs, foreground gc happens when disk is lack of free spaces,
it selects dirty segments and moves valid
From: Jin Xu
In f2fs_write_inode, updating inode after f2fs_balance_fs is not
a optimized way in the case that f2fs_gc is performed ahead. The
inode page will be unnecessarily written out twice, one of which
is in f2fs_gc->...->sync_node_pages and the other is in
update_inode_page.
Let&#x
From: Jin Xu
This patch fixes a deadlock bug that occurs quite often when there are
concurrent write and fsync on a same file.
Following is the simplified call trace when tasks get hung.
fsync thread:
- f2fs_sync_file
...
- f2fs_write_data_pages
...
- update_extent_cache
12 matches
Mail list logo
