linux-kernel - Re: running of out memory => kernel crash

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]

Date:	Wed, 17 Aug 2011 22:18:06 -0400
From:	Pavel Ivanov <paivanof@...il.com>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Mahmood Naderan <nt_mahmood@...oo.com>,
	David Rientjes <rientjes@...gle.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	"\"linux-kernel@...r.kernel.org\"" <linux-kernel@...r.kernel.org>,
	"\"linux-mm@...ck.org\"" <linux-mm@...ck.org>
Subject: Re: running of out memory => kernel crash

Denys,

>> Why "killing" does not appear here? Why it try to "find some
>> recently used page"?
>
> Because killing is the last resort. As long as kernel can free
> a page by dropping an unmodified file-backed page, it will do that.
> When there is nothing more to drop, and still more free pages
> are needed, _then_ kernel will start oom killing.

I have a little concern about this explanation of yours. Suppose we
have some amount of more or less actively executing processes in the
system. Suppose they started to use lots of resident memory. Amount of
memory they use is less than total available physical memory but when
we add total size of code for those processes it would be several
pages more than total size of physical memory. As I understood from
your explanation in such situation one process will execute its time
slice, kernel will switch to other one, find that its code was pushed
out of RAM, read it from disk, execute its time slice, switch to next
process, read its code from disk, execute and so on. So system will be
virtually unusable because of constantly reading from disk just to
execute next small piece of code. But oom will never be firing in such
situation. Is my understanding correct? Shouldn't it be considered as
an unwanted behavior?


Pavel


On Thu, Aug 11, 2011 at 1:38 PM, Denys Vlasenko
<vda.linux@...glemail.com> wrote:
> On Thursday 11 August 2011 17:13, Mahmood Naderan wrote:
>> >What it can possibly do if there is no swap and therefore it
>>
>> >can't free memory by writing out RAM pages to swap?
>>
>>
>> >the disk activity comes from constant paging in (reading)
>> >of pages which contain code of running binaries.
>>
>> Why the disk activity does not appear in the first scenario?
>
> Because there is nowhere to write dirty pages in order to free
> some RAM (since you have no swap) and reading in more stuff
> from disk can't possibly help with freeing RAM.
>
> (What kernel does in order to free RAM is it drops unmodified
> file-backed pages, and doing _that_ doesn't require disk I/O).
>
> Thus, no reading and no writing is necessary/possible.
>
>
>> >Thus the only option is to find some not recently used page
>> > with read-only, file-backed content (usually some binary's
>>
>> >text page, but can be any read-only file mapping) and reuse it.
>> Why "killing" does not appear here? Why it try to "find some
>>
>> recently used page"?
>
> Because killing is the last resort. As long as kernel can free
> a page by dropping an unmodified file-backed page, it will do that.
> When there is nothing more to drop, and still more free pages
> are needed, _then_ kernel will start oom killing.
--
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/