On Wed, Jul 29, 2015 at 08:55:01AM -0700, Andres Lagar-Cavilla wrote:

On Wed, Jul 29, 2015 at 8:28 AM, Vladimir Davydov
[off-list ref] wrote:

quoted

On Wed, Jul 29, 2015 at 04:26:19PM +0200, Michal Hocko wrote:

quoted

On Wed 29-07-15 16:59:07, Vladimir Davydov wrote:

quoted

On Wed, Jul 29, 2015 at 02:36:30PM +0200, Michal Hocko wrote:

quoted

On Sun 19-07-15 15:31:09, Vladimir Davydov wrote:
[...]

quoted

---- USER API ----

The user API consists of two new proc files:

I was thinking about this for a while. I dislike the interface.  It is
quite awkward to use - e.g. you have to read the full memory to check a
single memcg idleness. This might turn out being a problem especially on
large machines.

Yes, with this API estimating the wss of a single memory cgroup will
cost almost as much as doing this for the whole system.

Come to think of it, does anyone really need to estimate idleness of one
particular cgroup?

You can always adorn memcg with a boolean, trivially configurable from
user-space, and have all the idle computation paths skip the code if
memcg->dont_care_about_idle

Or we can filter out cgroups in which we're not interested using
/proc/kpagecgroup.

quoted

quoted

It is certainly interesting for setting the low limit.

Valuable, IMHO

quoted

Yes, but IMO there is no point in setting the low limit for one
particular cgroup w/o considering what's going on with the rest of the
system.

Probably worth more fleshing out. Why not? Because global reclaim can
execute in any given context, so a noisy neighbor hurts all?

The low limit does not necessarily mean, the cgroup will never get
pushed below it. It will, if others feel really bad.

Also, by setting the low limit too high, you can make others thrash
constantly, which will increase IO, which, in turn, might hurt the
workload you're trying to protect. Blkio cgroup might help in this case
though.

Thanks,
Vladimir