OOM-Killer kills too much with 2.6.32.2
in [Kernel]
|
Prev: [PATCH 0/3] Bunch of fixes related to custom atoi() implementation
Next: MAINTAINERS: Document new "Q:" patchwork queue type
From: Pekka Enberg on 26 Jan 2010 09:00 On Tue, Jan 26, 2010 at 7:19 AM, KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> wrote: > (cc to lots related person) > >> On Mon, 25 Jan 2010 02:48:08 +0100, KOSAKI Motohiro >> <kosaki.motohiro(a)jp.fujitsu.com> wrote: >> >> >> Hi, >> >> >> >> since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer >> >> kills when I do hard disk intensive tasks (mainly in VirtualBox which is >> >> running Windows XP) and IMHO it kills processes even if I have a lot of >> >> free memory. >> >> >> >> Is this a known bug? I have self compiled kernel so I can try patches. >> > >> > Can you please post your .config? > > Hi all, > > Strangely, all reproduce machine are x86_64 with Intel i915. but I don't > have any solid evidence. The same oops seems to appear in an unrelated "screen going blank" bug report (it's the second to last oops): http://bugzilla.kernel.org/show_bug.cgi?id=15015 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Reinelt on 26 Jan 2010 09:10 Michael Reinelt schrieb: > > Chris Wilson schrieb: >> On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> wrote: >>> Please consider to revert such commit at once. Lots people reported >>> the same issue. >>> I really hope to stop bug report storm. >> Your CC did not reference the problem that you were discussing, nor that >> it is even easier to trigger an OOM without the shrinker. Memory >> exhaustion due to the excess usage of surfaces from userspace is not a new >> issuer. So what is the problem you have encountered and how does running >> the OOM killer earlier fix the issue of triggering the OOM killer? >> > > To end this discussion: I just had a OOM with the GEM / shmem partial revert patch from Motohiro :-( > > Unfortunately without Motohiro's oom-debug patch applied :-( > > as a non-git-user I have to manually patch memory.c, but I hope I can get things right. I will provide results ASAP. Sorry sorry sorry... false alarm. One should also *install* a new kernel after compiling... I'll give it another try, this time with OOM debugging applied. sorry for the noise... -- Michael Reinelt <michael(a)reinelt.co.at> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Reinelt on 26 Jan 2010 09:20 Chris Wilson schrieb: > On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> wrote: >> Please consider to revert such commit at once. Lots people reported >> the same issue. >> I really hope to stop bug report storm. > > Your CC did not reference the problem that you were discussing, nor that > it is even easier to trigger an OOM without the shrinker. Memory > exhaustion due to the excess usage of surfaces from userspace is not a new > issuer. So what is the problem you have encountered and how does running > the OOM killer earlier fix the issue of triggering the OOM killer? > To end this discussion: I just had a OOM with the GEM / shmem partial revert patch from Motohiro :-( Unfortunately without Motohiro's oom-debug patch applied :-( as a non-git-user I have to manually patch memory.c, but I hope I can get things right. I will provide results ASAP. -- Michael Reinelt <michael(a)reinelt.co.at> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on 26 Jan 2010 19:20 > > - mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping, > > - GFP_HIGHUSER | > > - __GFP_COLD | > > - __GFP_FS | > > - __GFP_RECLAIMABLE | > > - __GFP_NORETRY | > > - __GFP_NOWARN | > > - __GFP_NOMEMALLOC); > > - > > kref_init(&obj->refcount); > > kref_init(&obj->handlecount); > > obj->size = size; > > I've applied this patch and I'm testing it right now. > Btw. what this patch will do from user(my) point of view? OOM Killer disappear :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Roman Jarosz on 27 Jan 2010 05:00
On Wed, 27 Jan 2010 01:14:44 +0100, KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> wrote: >> > - mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping, >> > - GFP_HIGHUSER | >> > - __GFP_COLD | >> > - __GFP_FS | >> > - __GFP_RECLAIMABLE | >> > - __GFP_NORETRY | >> > - __GFP_NOWARN | >> > - __GFP_NOMEMALLOC); >> > - >> > kref_init(&obj->refcount); >> > kref_init(&obj->handlecount); >> > obj->size = size; >> >> I've applied this patch and I'm testing it right now. >> Btw. what this patch will do from user(my) point of view? > > OOM Killer disappear :) Looks like the patch works... no oom kills so far. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |