[f2fs-dev] [PATCH] f2fs: fix the starvation problem on cp_rwsem
This patch removes the logic previously introduced to address the starvation
on cp_rwsem.
One potential there-in bug is that we should cover the wait.list with spin_lock,
but the previous code broke this rule.
And, actually current rwsem handles this starvation issue reasonably, so that we
didn't need to do this before neither.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h | 13 -
fs/f2fs/super.c | 1 -
2 files changed, 14 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index a955a59..308967b 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -18,8 +18,6 @@
#include
#include
#include
-#include
-#include
/*
* For mount options
@@ -360,7 +358,6 @@ struct f2fs_sb_info {
struct inode *meta_inode; /* cache meta blocks */
struct mutex cp_mutex; /* checkpoint procedure lock */
struct rw_semaphore cp_rwsem; /* blocking FS operations */
- wait_queue_head_t cp_wait; /* checkpoint wait queue */
struct mutex node_write;/* locking node writes */
struct mutex writepages;/* mutex for writepages() */
int por_doing; /* recovery is doing or not */
@@ -516,13 +513,6 @@ static inline void clear_ckpt_flags(struct f2fs_checkpoint
*cp, unsigned int f)
static inline void f2fs_lock_op(struct f2fs_sb_info *sbi)
{
- /*
-* If the checkpoint thread is waiting for cp_rwsem, add cuurent task
-* into wait list to avoid the checkpoint thread starvation
-*/
- while (!list_empty(&sbi->cp_rwsem.wait_list))
- wait_event_interruptible(sbi->cp_wait,
- list_empty(&sbi->cp_rwsem.wait_list));
down_read(&sbi->cp_rwsem);
}
@@ -539,9 +529,6 @@ static inline void f2fs_lock_all(struct f2fs_sb_info *sbi)
static inline void f2fs_unlock_all(struct f2fs_sb_info *sbi)
{
up_write(&sbi->cp_rwsem);
-
- /* wake up all tasks blocked by checkpoint */
- wake_up_all(&sbi->cp_wait);
}
/*
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 539c009..3b786c8 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -841,7 +841,6 @@ static int f2fs_fill_super(struct super_block *sb, void
*data, int silent)
spin_lock_init(&sbi->stat_lock);
init_rwsem(&sbi->bio_sem);
init_rwsem(&sbi->cp_rwsem);
- init_waitqueue_head(&sbi->cp_wait);
init_sb_info(sbi);
/* get an inode for meta space */
--
1.8.4.474.g128a96c
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] f2fs using tons of cpu
Hi, 2013-10-08 (화), 13:25 +0200, folkert: > Hi, > > For the last few days f2fs started to use loads of cpu on one of my > raspberry pi systems: > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 2822 root 20 0 000 R 35.3 0.0 328:34.01 f2fs_gc-254:0 > 2826 root 20 0 000 R 35.3 0.0 327:40.07 flush-254:0 The f2fs_gc is a kernel thread conducting on-line defragementation. The period between each triggers is dependant on the system idling time, ranging from 30 to 60 secs by default. In order to control these times, you can use sysfs enabled by the following patch that was merged into 3.12-rc1. commit d2dc095f4280ad5fdea33769e8e119fd16648426 f2fs: add sysfs entries to select the gc policy commit b59d0bae6ca30c496f298881616258f9cde0d9c6 f2fs: add sysfs support for controlling the gc_thread > This is continuous load, the whole day. Right. It runs until there is no fragmentation. > This is to a SSD connected via USB: > Bus 001 Device 025: ID 0c45:7401 Microdia > The SSD does not support trim (that's why I put f2fs on it). > > It is constantly reading (and not writing) data from the SSD it is on: The f2fs_gc just loads a bunch of victim blocks from the disk to in-memory cache first. Afterwards, it writes cached blocks by the write-back mechanism in VFS according to the system status. > > folkert@vnvnation ~ $ vmstat 2 > procs ---memory-- ---swap-- -io -system-- cpu > r b swpd free buff cache si sobibo in cs us sy id wa > 2 0 0 20744 16 37505200 305774 0 413 157 0 100 0 > 0 > 2 0 0 20744 16 37505200 304272 0 409 151 0 100 0 > 0 > 2 0 0 21536 16 37505200 301444 0 410 163 0 100 0 > 0 > 2 0 0 21536 16 37505200 305052 0 408 150 0 100 0 > 0 > 2 0 0 21536 16 37505200 302994 0 407 151 0 100 0 > 0 > 2 0 0 21932 16 37505200 303408 0 406 153 0 100 0 > 0 > 2 0 0 21932 16 37505200 301580 0 417 152 1 99 0 0 > 2 0 0 21932 16 37505200 304142 0 411 150 0 100 0 > 0 > 2 0 0 21932 16 37505200 305944 0 409 152 0 100 0 > 0 > 2 0 0 21932 16 37505200 299700 0 414 156 0 100 0 > 0 > > It has lots of free diskspace left: You'd better keep track on /sys/kernel/debug/f2fs/status, and I think you can find many dirty segments across the partition. In the status file, you can also see the f2fs_gc behavior. Thanks, > > folkert@vnvnation ~ $ df -h /home/folkert/backups > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/backups 118G 91G 27G 78% /home/folkert/backups > > Kernel: > > folkert@vnvnation ~ $ uname -r > 3.9.8+ > > > Folkert van Heusden > -- Jaegeuk Kim Samsung -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
