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: <20090628112748.2470f2d5@infradead.org>
Date:	Sun, 28 Jun 2009 11:27:48 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pavel Machek <pavel@....cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	penberg@...helsinki.fi, linux-kernel@...r.kernel.org,
	cl@...ux-foundation.org, npiggin@...e.de
Subject: Re: upcoming kerneloops.org item: get_page_from_freelist

On Sun, 28 Jun 2009 11:01:42 -0700 (PDT)
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> The _other_ part of memory management that you and Andrew seem to be 
> ignoring is that it's very robust, and keeps extra memory around, and
> just generally does the right thing. We don't generally pre-allocate
> anything, because we don't need to.

... and if there is a real concern, the real solution is to have a way
to request that the VM temporarily increases the amount of extra memory.
Preferably before you go down a path of hardship so that the VM can
do some work to satisfy the request.

There are a few places where having (small) local reserves make sense of
course, mostly in the write out paths like the block layer. And we do
that already.

> 
> Almost the _only_ way to run out of memory is to have tons and tons
> of dirty pages around. Yes, it can happen. But if it happens, you're
> almost guaranteed to be screwed anyway. The whole VM is designed

my impression is that when the strict dirty accounting code went in,
this problem largely went away.

The other problem is pinned memory, but this was mostly a
lowmem/highmem thing, and time (and 64 bit) seems to have mostly solved
the more common cases of those.

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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