Messages in this thread | | | Date | Wed, 19 Aug 2009 15:49:58 +0900 | From | Minchan Kim <> | Subject | Re: abnormal OOM killer message |
| |
On Wed, 19 Aug 2009 15:24:54 +0900 우충기 <chungki.woo@gmail.com> wrote:
> Thank you very much for replys. > > But I think it seems not to relate with stale data problem in compcache. > My question was why last chance to allocate memory was failed. > When OOM killer is executed, memory state is not a condition to > execute OOM killer. > Specially, there are so many pages of order 0. And allocating order is zero. > I think that last allocating memory should have succeeded. > That's my worry.
Yes. I agree with you. Mel. Could you give some comment in this situation ? Is it possible that order 0 allocation is failed even there are many pages in buddy ?
> > ----------------------------------------------------------------------------------------------------------------------------------------------- > page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, order, > <== this is last chance > zonelist, ALLOC_WMARK_HIGH|ALLOC_CPUSET); > <== uses ALLOC_WMARK_HIGH > if (page) > goto got_pg; > > out_of_memory(zonelist, gfp_mask, order); > goto restart; > ----------------------------------------------------------------------------------------------------------------------------------------------- > > > Let me have a question. > > Now the system has 79M as total swap. > > It's bigger than system memory size. > > Is it possible in compcache? > > Can we believe the number? > > Yeah, It's possible. 79Mbyte is data size can be swap. > It's not compressed data size. It's just original data size.
You means your pages with 79M are swap out in compcache's reserved memory?
> > Thanks, > Minchan, Nitin
-- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |