linux-kernel - Re: abnormal OOM killer message

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: <18eba5a10908182324x45261d06y83e0f042e9ee6b20@mail.gmail.com>
Date:	Wed, 19 Aug 2009 15:24:54 +0900
From:	우충기 <chungki.woo@...il.com>
To:	Minchan Kim <minchan.kim@...il.com>
Cc:	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,
	Mel Gorman <mel@....ul.ie>
Subject: Re: abnormal OOM killer message

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.

-----------------------------------------------------------------------------------------------------------------------------------------------
      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.

Thanks,
Minchan, Nitin
--
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/