Re: [RFC][PATCH 1/4] Memory controller soft limit documentation

[Balbir Singh]

* Paul Menage <menage@xxxxxxxxxx> [2009-01-13 17:45:54]:

> On Wed, Jan 7, 2009 at 10:41 AM, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:
> > -7. TODO
> > +7. Soft limits
> > +
> > +Soft limits allow for greater sharing of memory. The idea behind soft limits
> > +is to allow control groups to use as much of the memory as needed, provided
> > +
> > +a. There is no memory contention
> > +b. They do not exceed their hard limit
> > +
> > +When the system detects memory contention (through do_try_to_free_pages(),
> > +while allocating), control groups are pushed back to their soft limits if
> > +possible. If the soft limit of each control group is very high, they are
> > +pushed back as much as possible to make sure that one control group does not
> > +starve the others.
> 
> Can you give an example here of how to implement the following setup:
> 
> - we have a high-priority latency-sensitive server job A and a bunch
> of low-priority batch jobs B, C and D
> 
> - each job *may* need up to 2GB of memory, but generally each tends to
> use <1GB of memory
> 
> - we want to run all four jobs on a 4GB machine
> 
> - we don't want A to ever have to wait for memory to be reclaimed (as
> it's serving latency-sensitive queries), so the kernel should be
> squashing B/C/D down *before* memory actually runs out.
> 
> Is this possible with the proposed hard/soft limit setup? Or do we
> need some additional support for keeping a pool of pre-reserved free
> memory available?

This is a more complex scenario, It sounds like B/C and D should be
hard limited to 2G or another value, depending on how much you want to
pre-reserve for A (all B/C and D should be in the same cgroup). Then
you want to use soft limits within the B/C/D cgroup. You don't want to
hard limit A, but just setup a 2G soft limit for it.

The notion of prioritized jobs and reservation does not exist yet, but
once we support soft limits and overcommit via soft limits, we could
consider looking at what design aspects would help with it.

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