lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090819154958.18a34aa5.minchan.kim@barrios-desktop>
Date:	Wed, 19 Aug 2009 15:49:58 +0900
From:	Minchan Kim <minchan.kim@...il.com>
To:	우충기 <chungki.woo@...il.com>,
	Mel Gorman <mel@....ul.ie>
Cc:	Minchan Kim <minchan.kim@...il.com>, ngupta@...are.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	fengguang.wu@...el.com, riel@...hat.com, akpm@...ux-foundation.org,
	kosaki.motohiro@...fujitsu.com
Subject: Re: abnormal OOM killer message

On Wed, 19 Aug 2009 15:24:54 +0900
우충기 <chungki.woo@...il.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ