Messages in this thread | | | Date | Sat, 21 Apr 2007 03:54:44 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 10/10] mm: per device dirty threshold |
| |
On Sat, 21 Apr 2007 12:38:45 +0200 Miklos Szeredi <miklos@szeredi.hu> wrote:
> The other deadlock, in throttle_vm_writeout() is still to be solved.
Let's go back to the original changelog:
Author: marcelo.tosatti <marcelo.tosatti> Date: Tue Mar 8 17:25:19 2005 +0000
[PATCH] vm: pageout throttling With silly pageout testcases it is possible to place huge amounts of memory under I/O. With a large request queue (CFQ uses 8192 requests) it is possible to place _all_ memory under I/O at the same time. This means that all memory is pinned and unreclaimable and the VM gets upset and goes oom. The patch limits the amount of memory which is under pageout writeout to be a little more than the amount of memory at which balance_dirty_pages() callers will synchronously throttle. This means that heavy pageout activity can starve heavy writeback activity completely, but heavy writeback activity will not cause starvation of pageout. Because we don't want a simple `dd' to be causing excessive latencies in page reclaim. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
(A good one! I wrote it ;))
I believe that the combination of dirty-page-tracking and its calls to balance_dirty_pages() mean that we can now never get more than dirty_ratio of memory into the dirty-or-writeback condition.
The vm scanner can convert dirty pages into clean, under-writeback pages, but it cannot increase the total of dirty+writeback.
Hence I assert that the problem which throttle_vm_writeout() was designed to address can no longer happen, so we can simply remove it.
(There might be problems with ZONE_DMA or ZONE_NORMAL 100% full of dirty+writeback pages, but throttle_vm_writeout() wont help in this case anyway) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |