On Tue, 2008-08-19 at 22:15 +0530, Balbir Singh wrote:
quoted text
> Dave Hansen wrote:
> > 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.

OK, let's get back to describing the basic problem here.  What is the
basic problem being solved?  Applications basically want to get a
failure back from malloc() when the machine is (nearly?) out of memory
so they can stop consuming?

Is this the only way to do autonomic computing with memory?  Or, are
there other or better approaches?

Surely an autonomic computing app could keep track of its own memory
footprint.  

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.

Heh.  That suggestion is, at best, working around a kernel bug.  The DB
guys are just saying to do that because they're the biggest memory users
and always seem to get OOM killed first.

The base problem here is the OOM killer, not an application that truly
uses memory overcommit restriction in an interesting way.

quoted text
> 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

I think that too many of the users of (1) probably fall into the
PostgreSQL category.  They found that turning it on "fixed" their bugs,
but it really just swept them under the rug.

So, before we expand the use of those features to control groups by
adding a bunch of new code, let's make sure that there will be users for
it and that those users have no better way of doing it.

-- Dave

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