From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 30 Aug 2004 11:39:34 +0200 Message-ID: From: Takashi Iwai Subject: Re: OOM-killer for zone DMA? In-Reply-To: <413021BA.3090908@yahoo.com.au> References: <413021BA.3090908@yahoo.com.au> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: linux-mm@kvack.org List-ID: At Sat, 28 Aug 2004 16:10:02 +1000, Nick Piggin wrote: > > Takashi Iwai wrote: > > Hi, > > > > In the primary version of my DMA allocation patch, I tried to allocate > > pages with GFP_DMA as much as possible, then allocate with GFP_KERNEL > > as fallback. But this doesn't work. When the zone DMA is exhausted, > > I oberseved endless OOM-killer. > > > > Is this a desired behavior? I don't think triggering OOM-killer for > > zone DMA makes sense, because apps don't allocate pages in this > > area... > > > > They easily could. > > > Note that the driver tried to allocate bunch of single pages with > > GFP_DMA, not big pages, by calling dma_alloc_coherent with GFP_DMA > > only (no __GFP_REPEAT or such modifiers). > > > > You at least need __GFP_NORETRY to achieve what you want. Yes, with that flag it can be avoided. But it *should* retry. It's an allocation of single page, and the caller of dma_alloc_coherent() doesn't know whether it's allocated from zone DMA or zone normal. It sets just the coherent_dma_mask to a value less than 32 bit. This situation may happen even after applying my patch. If you have more RAM than mask, allocation in the zone NORMAL may hit the outside of mask, and tries the zone DMA as fallback, although there are pretty enough free RAM in the zone NORMAL. So, triggering oom-killer for zone DMA is non-sense, IMO. Takashi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: aart@kvack.org