| To: | Minchan Kim <minchan.kim@xxxxxxxxx> |
|---|---|
| Subject: | Re: 2.6.39-rc4+: oom-killer busy killing tasks |
| From: | Christian Kujau <lists@xxxxxxxxxxxxxxx> |
| Date: | Thu, 21 Apr 2011 20:03:27 -0700 (PDT) |
| Cc: | LKML <linux-kernel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <BANLkTi=P5z4iON+ULiUEAeuuCJCJ_nMxWw@xxxxxxxxxxxxxx> |
| References: | <alpine.DEB.2.01.1104211841510.18728@xxxxxxxxxxxxxx> <BANLkTi=P5z4iON+ULiUEAeuuCJCJ_nMxWw@xxxxxxxxxxxxxx> |
| User-agent: | Alpine 2.01 (DEB 1266 2009-07-14) |
On Fri, 22 Apr 2011 at 11:58, Minchan Kim wrote: > But I wonder why VM can't reclaim the pages. As I see the log, there > are lots of slab pages(710M) in DMA zone while LRU pages are very > small. SLAB pages are things VM has a trouble to reclaim. I am not > sure 710M of SLAB is reasonable size. Don't you have experience same > problem in old kernel? No, I forgot to add 2.6.38 (and before) did not show that behaviour. > If you see the problem first in 2.6.39-rc4, maybe it would be a > regression(ex, might be slab memory leak) I would think so. I'll try to bisect, but with one compilation taking ~20min on this box, this might take a while. > Could you get the information about slabinfo(ex, cat /proc/slabinfo) > right before OOM happens. When it happens again, I'll try to get this. Thanks for replying, Christian. -- BOFH excuse #73: Daemons did it |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: 2.6.39-rc4+: oom-killer busy killing tasks, Minchan Kim |
|---|---|
| Next by Date: | Re: [PATCH 3/4] xfs: exact busy extent tracking, Christoph Hellwig |
| Previous by Thread: | Re: 2.6.39-rc4+: oom-killer busy killing tasks, Minchan Kim |
| Next by Thread: | Re: 2.6.39-rc4+: oom-killer busy killing tasks, Christian Kujau |
| Indexes: | [Date] [Thread] [Top] [All Lists] |