Hi, On Fri, 5 May 2006 17:28:06 +0200 "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote:
> This is an example: > > [ 1151.984763] oom-killer: gfp_mask=0x80d2, order=0 Huh? If I understand Linux' memory management correctly that says that the OOM condition was triggered by trying to reserve 1 page (order=0) of high memory (gfp_mask|0x0002). But: You don't have highmem (of course, because you're running on 64bit). > [ 1151.984770] DMA per-cpu: what about DMA32? Is this an older kernel? > [ 1151.984809] HighMem free:0kB min:128kB low:160kB high:192kB active:0kB > inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no doesn't make me wonder on 64bit... > [ 1151.984829] Swap cache: add 71, delete 71, find 0/0, race 0+0 > [ 1151.984831] Free swap = 995736kB > [ 1151.984833] Total swap = 996020kB > [ 1151.984834] Free swap: 995736kB Errr, that basically says nearly full swap space is available, isn't it? I think you probably have some IO related driver that for whatever reason decides to claim highmem. This triggers the OOM (there's no highmem), and cc1plus just happens to be the most interesting task to kill for the kernel: - just started, - much memory recovered Further analysis would probably require patching the mm/oom_kill.c and inserting a few debug statements -- if the problem is still there for newest kernels (there's been some changes esp. reg. AMD64 in 2.6.14, IIRC). -hwh -- gentoo-user@gentoo.org mailing list
