On Mon, Apr 29, 2013 at 04:57:11PM +0200, Michal Hocko wrote: > On Mon 29-04-13 14:50:08, Christoph Lameter wrote: > > On Sat, 27 Apr 2013, Han Pingtian wrote: > > > > > and it is called so many times that the boot cannot be finished. So > > > maybe the memory isn't freed even though __free_slab() get called? > > > > Ok that suggests an issue with the page allocator then. > > You seem to have CONFIG_MEMCG_KMEM enabled. Do you see the same issue > when this is disabled? The kmem accounting should be disabled unless a > specific limit is set but it would be better to know that this is not > the factor. > I have tested to disable CONFIG_MEMCG_KMEM. But it doesn't solve this problem, I can still trigger the OOM by compiling kernel. Now I suspect the problem comes from the driver "ibmvscsi". Because on another power 7 system, which doesn't use ibmvscsi, there is no such OOM problem here. For now, looks like only systems using ibmvscsi can trigger this OOM problem. I have rebooted one of the ibmvscsi systems with "init=/bin/sh" and compared the loaded modules with one of the none-ibmvscsi system with "comm": $ comm -13 --check-order none-ibmvscsi.txt ibmvscsi.txt ibmvscsi nx_crypto scsi_transport_srp the scsi_transport_srp is used by ibmvscsi and I can rmmod the nx_crypto out. Then I launched the compiling process on the single-user-booted ibmvscsi system. The OOM can still be produced on it. Looks like "ibmvscsi" + "slub" can trigger this problem. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>