]> git.baikalelectronics.ru Git - kernel.git/commit
mm, writeback: flush plugged IO in wakeup_flusher_threads()
authorKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
Thu, 4 Aug 2016 18:36:05 +0000 (21:36 +0300)
committerJens Axboe <axboe@fb.com>
Wed, 10 Aug 2016 01:58:06 +0000 (19:58 -0600)
commite2e9e6ec9bfa86b63b6a7b66637065b1e2b3bf97
tree775b636093a744285f6226337a16d99020d1ee6d
parentc8583f2f3b4fb45d894ac5cc35edf438a8287ee8
mm, writeback: flush plugged IO in wakeup_flusher_threads()

I've found funny live-lock between raid10 barriers during resync and
memory controller hard limits. Inside mpage_readpages() task holds on to
its plug bio which blocks the barrier in raid10. Its memory cgroup have
no free memory thus the task goes into reclaimer but all reclaimable
pages are dirty and cannot be written because raid10 is rebuilding and
stuck on the barrier.

Common flush of such IO in schedule() never happens, because the caller
doesn't go to sleep.

Lock is 'live' because changing memory limit or killing tasks which
holds that stuck bio unblock whole progress.

That was what happened in 3.18.x but I see no difference in upstream
logic.  Theoretically this might happen even without memory cgroup.

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Jens Axboe <axboe@fb.com>
fs/fs-writeback.c