linux-kernel - Re: [PATCH] Memory usage limit notification addition to memcg

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: <20090413165404.b6660aea.akpm@linux-foundation.org>
Date:	Mon, 13 Apr 2009 16:54:04 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Dan Malek <dan@...eddedalley.com>
Cc:	linux-kernel@...r.kernel.org, menage@...gle.com,
	containers@...ts.linux-foundation.org
Subject: Re: [PATCH] Memory usage limit notification addition to memcg

On Mon, 13 Apr 2009 16:45:17 -0700
Dan Malek <dan@...eddedalley.com> wrote:

> On Apr 13, 2009, at 4:08 PM, Andrew Morton wrote:
> 
> > We've run into problems in the past where a percentage number is too
> > coarse on large-memory systems.
> >
> > Proabably that won't be an issue here, but I invite you to convince us
> > of this ;)
> 
> The challenge here is that the absolute limit of the memcg can
> be dynamically changed, so I wanted to avoid a couple of problems.
> One is just a system configuration error where someone forgets
> to modify both.  For example, if you start with the memcg limit of 100M,
> and the notification limit to 80M, then come back and change the memcg
> limit to 90M (or worse, < 80M) you now have a clearly incorrect
> configuration.   Another problem is the operation isn't atomic, at some
> point during the changes, even if you remember to do it correctly, you
> will have the two values not representing what you really want.  It
> could trigger an erroneous notification, or simply OOM kill before you
> get the configuration correct.
> 
> If an integer number turns out to not be sufficient, we could change  
> this
> to some fixed point representation and adjust the arithmetic in the  
> tests.
> I believe the integer number will be fine, even in large memory systems.
> This is just a notification model, if we want something more fine  
> grained
> I believe it would need different semantics.

I agree.  But it would be a mighty mess if we were to turn around in
two years time and add a second centi-percent interface.  So we should
give this careful thought now and really convince ourselves that we
will never ever ever want sub-1% resolution.


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