Re: [PATCH v2 1/3] cgroup: define controller file conventions

[Michal Hocko]

On Thu 06-08-15 11:30:08, KAMEZAWA Hiroyuki wrote:
[...]
> Sure. I think following has users.
>  - *.stat             - for chekcing health of cgroup ,or for debug

Yes but we want to have something which is closer to meminfo/vmstat IMO

>  - *.pressure_level   - for notifying memory pressure

Notifications are definitely useful I am just not sure this interface is
the right one. We have seen some requests to adjust the interface to get
new semantics (edge vs. level triggered). This should be sorted out
before we expose the knob.

>  - *.swappiness       - for adjusting LRU activity per application type.

Yes, and I wanted to post a patch to export it several times but then I
realized that this should be done only as long as vm.swappiness stays
and it is not deprecated. And more and more I think about swappiness
the less sure I am about it's usefulness. It is not doing much for
quite some time because we are heavily biasing to the pagecache reclaim
and the knob is more and more misleading. It is also not offering what
people might want it to do. E.g. it doesn't allow for preferring swapout
which might be useful when the swap is backed by a really fast storage.
Maybe we will need a new metric here so I wouldn't rush exporting memcg
alternative much.

>  - *.oom_control      - for surviving/notifiyng out of memory
>                         memcg's oom can be recovered if limit goes up rather than kill.

I think it is very much useful - when used wisely. I have seen many
calls for user defined OOM policies but then we have seen those that are
more creative like having the policy maker live in the same memcg which
requires some hacks to prevent from self-deadlocks.
So overall this is very attractive but we might need to think about a
better interface. BPF sounds like a potential way to go. I feel the
memcg and the global approaches should be consistent as much as possible
wrt. API.
-- 
Michal Hocko
SUSE Labs
--
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/