Re: oom-killer why ?

[Balbir Singh <balbir@linux.vnet.ibm.com>]

Balbir Singh wrote:
> Marco Nietz wrote:
>> Balbir Singh schrieb:
>>
>>>> DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB
>>>> present:0kB pages_scanned:0 all_unreclaimable? no
>>>> lowmem_reserve[]: 0 0 880 17392
>>> pages_scanned is 0
>> Is'nt this zone irrelevant for a 32bit Kernel ?
>>
> 
> Doesn't matter, since you have 0 present pages.
> 
>>>> Normal free:3664kB min:3756kB low:4692kB high:5632kB active:280kB
>>>> inactive:244kB present:901120kB pages_scanned:593 all_unreclaimable? yes
>>>> lowmem_reserve[]: 0 0 0 132096
>>> pages_scanned is 593 and all_unreclaimable is yes
>> Reclaimable means, that the Pages are reusable for other Purposes, or not ?
>>
> 
> It is set by a background routine that tries to reclaim pages (balance_pgdat()),
> to indicate that it was unable to reclaim any pages from the zone, even though
> it did a certain amount of work to do so.
> 
>>>> HighMem free:5941820kB min:512kB low:18148kB high:35784kB
>>>> active:4408096kB inactive:5494404kB present:16908288kB pages_scanned:0
>>>> all_unreclaimable? no
>>> pages_scanned is 0
>>> Do you have CONFIG_HIGHPTE set? I suspect you don't (I don't really know the
>>> debian etch configuration)
>> No, it's not set in the running Debian Kernel.
> 
> Looks like CONFIG_HIGHPTE=y would have helped allocate pages since you do have
> pages in HighMem available.
> 

Looking closely, may be there is a leak like Christoph suggested (most of the
pages have been consumed by the kernel) - only 280kB+244kB is in use by user
pages. The rest has either leaked or in use by the kernel.

-- 
	Balbir

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>