diff options
| -rw-r--r-- | fs/jffs2/background.c | 18 |
1 files changed, 11 insertions, 7 deletions
diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c index 3cceef4ad2b7..e9580104b6ba 100644 --- a/fs/jffs2/background.c +++ b/fs/jffs2/background.c | |||
| @@ -95,13 +95,17 @@ static int jffs2_garbage_collect_thread(void *_c) | |||
| 95 | spin_unlock(&c->erase_completion_lock); | 95 | spin_unlock(&c->erase_completion_lock); |
| 96 | 96 | ||
| 97 | 97 | ||
| 98 | /* This thread is purely an optimisation. But if it runs when | 98 | /* Problem - immediately after bootup, the GCD spends a lot |
| 99 | other things could be running, it actually makes things a | 99 | * of time in places like jffs2_kill_fragtree(); so much so |
| 100 | lot worse. Use yield() and put it at the back of the runqueue | 100 | * that userspace processes (like gdm and X) are starved |
| 101 | every time. Especially during boot, pulling an inode in | 101 | * despite plenty of cond_resched()s and renicing. Yield() |
| 102 | with read_inode() is much preferable to having the GC thread | 102 | * doesn't help, either (presumably because userspace and GCD |
| 103 | get there first. */ | 103 | * are generally competing for a higher latency resource - |
| 104 | yield(); | 104 | * disk). |
| 105 | * This forces the GCD to slow the hell down. Pulling an | ||
| 106 | * inode in with read_inode() is much preferable to having | ||
| 107 | * the GC thread get there first. */ | ||
| 108 | schedule_timeout_interruptible(msecs_to_jiffies(50)); | ||
| 105 | 109 | ||
| 106 | /* Put_super will send a SIGKILL and then wait on the sem. | 110 | /* Put_super will send a SIGKILL and then wait on the sem. |
| 107 | */ | 111 | */ |