Re: oom-killer why ?

Balbir Singh
2008-08-26T13:15:38Z

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.

--
Balbir