Dave Hansen wrote:
quoted text
> On Tue, 2008-08-19 at 12:48 +0530, Balbir Singh wrote:
>> 1. To provide a soft landing mechanism for applications that exceed their memory
>> limit. Currently in the memory resource controller, we swap and on failure OOM.
>> 2. To provide a mechanism similar to memory overcommit for control groups.
>> Overcommit has finer accounting, we just account for virtual address space usage.
>> 3. Vserver will directly be able to port over on top of memrlimit (their address
>> space limitation feature)
> 
> Balbir,
> 
> This all seems like a little bit too much hand waving to me.  I don't

Dave, there is no hand waving, just an honest discussion. Although, you may not
see it in the background, we still need overcommit protection and we have it
enabled by default for the system. There are applications that can deal with the
constraints setup by the administrator and constraints of the environment,
please see http://en.wikipedia.org/wiki/Autonomic_computing.

quoted text
> really see a single concrete user in the "potential applications" here.
> I really don't understand why you're pushing this so hard if you don't
> have anyone to actually use it.
> 
> I just don't see anyone that *needs* it.  There's a lot of "it would be
> nice", but no "needs".

If you see the original email, I've sent - I've mentioned that we need
overcommit support (either via memrlimit or by porting over the overcommit
feature) and the exploiters you are looking for is the same as the ones who need
overcommit and RLIMIT_AS support.

On the memory overcommit front, please see PostgreSQL Server Administrator's
Guide at
http://www.network-theory.co.uk/docs/postgresql/vol3/LinuxMemoryOvercommit.html

The guide discusses turning off memory overcommit so that the database is never
OOM killed, how do we provide these guarantees for a particular control group?
We can do it system wide, but ideally we want the control point to be per
control group.

As far as other users are concerned, I've listed users of the memory limit
feature, in the original email I sent out. To try and understand your viewpoint
better, could you please tell me if

1. You are opposed to overcommit and RLIMIT_AS as features

OR

2. Expanding them to control groups

-- 
	Balbir
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/