Hmm.. I can believe it. The code that waits on bdflush in wakeup_bdflush()
is somewhat suspicious. In particular, if/when that ever triggers, and
bdflush() is busy in flush_dirty_buffers(), then the process that is
trying to wake bdflush up is going to wait until flush_dirty_buffers() is
done.
Which, if there is a process dirtying pages, can basically be
pretty much forever.
This was probably hidden by the lower limits simply by virtue of bdflush
never being very active before.
What does the system feel like if you just change the "sleep for bdflush"
logic in wakeup_bdflush() to something like
wake_up_process(bdflush_tsk);
__set_current_state(TASK_RUNNING);
current->policy |= SCHED_YIELD;
schedule();
instead of trying to wait for bdflush to wake us up?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/