Messages in this thread | | | Date | Wed, 5 Jan 2005 17:36:24 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH][5/?] count writeback pages in nr_scanned |
| |
Rik van Riel <riel@redhat.com> wrote: > > On Thu, 6 Jan 2005, Nick Piggin wrote: > > > I think what Andrea is worried about is that blk_congestion_wait is > > fairly vague, and can be a source of instability in the scanning > > implementation. > > The recent OOM kill problem has been happening: > 1) with cache pressure on lowmem only, due to a block device write > 2) with no block congestion at all > 3) with pretty much all pageable lowmme pages in writeback state
You must have a wild number of requests configured in the queue. Is this CFQ?
I've done testing with "all of memory under writeback" before and it went OK. It's certainly a design objective to handle this well. But that testing was before we broke it.
> It appears the VM has trouble dealing with the situation where > there is no block congestion to wait on...
It's misnamed. We don't "wait for the queue to come out of congestion". We simply throttle until a write completes, or, rarely, timeout.
The bug which you fixed would cause the VM to scan itself to death without throttling. Did the fix fix things? - 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/
| |