Messages in this thread |  | | | Date | Thu, 11 Nov 2004 16:42:38 +0100 | | From | Andrea Arcangeli <> | | Subject | Re: [PATCH] fix spurious OOM kills |
| |
On Thu, Nov 11, 2004 at 09:29:22AM -0200, Marcelo Tosatti wrote: > Hi, > > This is an improved version of OOM-kill-from-kswapd patch. > > I believe triggering the OOM killer from task reclaim context > is broken because the chances that it happens increases as the amount > of tasks inside reclaim increases - and that approach ignores efforts > being done by kswapd, who is the main entity responsible for > freeing pages. > > There have been a few problems pointed out by others (Andrea, Nick) on the > last patch - this one solves them.
I disagree about the design of killing anything from kswapd. kswapd is an async helper like pdflush and it has no knowledge on the caller (it cannot know if the caller is ok with the memory currently available in the freelists, before triggering the oom). I'm just about to move the oom killing away from vmscan.c to page_alloc.c which is basically the opposite of moving the oom invocation from the task context to kswapd. page_alloc.c in the task context is the only one who can know if something has to be killed, vmscan.c cannot know. vmscan.c can only know if something is still freeable, but if something isn't freeable it doesn't mean that we've to kill anything (for example if a task exited or some dma or normal-zone or highmem memory was released by another task while we were paging waiting for I/O). Every allocation is different and page_alloc.c is the only one who knows what has to be done for every single allocation. - 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/
|  |