linux-kernel - Re: [PATCH -v2 -mm] add extra free kbytes tunable

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:	Thu, 13 Oct 2011 17:11:59 -0400
From:	Rik van Riel <riel@...hat.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	Satoru Moriya <satoru.moriya@....com>,
	Con Kolivas <kernel@...ivas.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Satoru Moriya <smoriya@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	"lwoodman@...hat.com" <lwoodman@...hat.com>,
	Seiji Aguchi <saguchi@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	"hannes@...xchg.org" <hannes@...xchg.org>
Subject: Re: [PATCH -v2 -mm] add extra free kbytes tunable

On 10/13/2011 04:48 PM, David Rientjes wrote:

> We'll never know the future and how much memory a latency-sensitive
> application will require 100ms from now.  The only thing that we can do is
> (i) identify the latency-sensitive app, (ii) reclaim more aggressively for
> them, and (iii) reclaim additional memory in preparation for another

This is why I proposed a watermark solution.

> burst.  At some point, though, userspace needs to be responsible to not
> allocate enormous amounts of memory all at once and there's room for
> mitigation there too to preallocate ahead of what you actually need.

Userspace cannot be responsible, for the simple reason that
the allocations might be done in the kernel.

Think about an mlocked realtime program handling network
packets. Memory is allocated when packets come in, and when
the program calls sys_send(), which causes packets to get
sent.

I don't see how we can make userspace responsible for
kernel-side allocations.

I did not propose the extra_free_kbytes patch because I
like it, or out of laziness, but because I truly have not
come up with a better solution.

So far, neither this thread (which is unfortunate).
--
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/