We actually started with kernel patches all h these lines - per-memcg scores and all of our crazy policy requirements.
It turns out that changing policies is hard.
When David offered the opportunity to manage it all in user space it sounded like a great idea.
If this can be made to work as a high prio daemon with access to reserves, we would like it.
Tim
On Dec 6, 2013 9:36 AM, "Johannes Weiner" <hannes@xxxxxxxxxxx> wrote:
On Thu, Dec 05, 2013 at 03:49:57PM -0800, David Rientjes wrote:
> On Wed, 4 Dec 2013, Tejun Heo wrote:
>
> > Hello,
> >
>
> Tejun, how are you?
>
> > Umm.. without delving into details, aren't you basically creating a
> > memory cgroup inside a memory cgroup? Doesn't sound like a
> > particularly well thought-out plan to me.
> >
>
> I agree that we wouldn't need such support if we are only addressing memcg
> oom conditions. We could do things like A/memory.limit_in_bytes == 128M
> and A/b/memory.limit_in_bytes == 126MB and then attach the process waiting
> on A/b/memory.oom_control to A and that would work perfect.
>
> However, we also need to discuss system oom handling. We have an interest
> in being able to allow userspace to handle system oom conditions since the
> policy will differ depending on machine and we can't encode every possible
> mechanism into the kernel. For example, on system oom we want to kill a
> process from the lowest priority top-level memcg. We lack that ability
> entirely in the kernel and since the sum of our top-level memcgs
> memory.limit_in_bytes exceeds the amount of present RAM, we run into these
> oom conditions a _lot_.
A simple and natural solution to this is to have the global OOM killer
respect cgroups. You go through all the effort of carefully grouping
tasks into bigger entities that you then arrange hierarchically. The
global OOM killer should not just treat all tasks as equal peers.
We can add a per-cgroup OOM priority knob and have the global OOM
handler pick victim tasks from the one or more groups that have the
lowest priority.
Out of the box, every cgroup has the same priority, which means we can
add this feature without changing the default behavior.
> So the first step, in my opinion, is to add a system oom notification on
> the root memcg's memory.oom_control which currently allows registering an
> eventfd() notification but never actually triggers. I did that in a patch
> and it is was merged into -mm but was pulled out for later discussion.
>
> Then, we need to ensure that the userspace that is registered to handle
> such events and that is difficult to do when the system is oom. The
> proposal is to allow such processes, now marked as PF_OOM_HANDLER, to be
> able to access pre-defined per-zone memory reserves in the page allocator.
> The only special handling for PF_OOM_HANDLER in the page allocator itself
> would be under such oom conditions (memcg oom conditions have no problem
> allocating the memory, only charging it). The amount of reserves would be
> defined as memory.oom_reserve_in_bytes from within the root memcg as
> defined by this patch, i.e. allow this amount of memory to be allocated in
> the page allocator for PF_OOM_HANDLER below the per-zone min watermarks.
>
> This, I believe, is the cleanest interface for users who choose to use a
> non-default policy by setting memory.oom_reserve_in_bytes and constrains
> all of the code to memcg which you have to configure for such support.
>
> The system oom condition is not addressed in this patch series, although
> the PF_OOM_HANDLER bit can be used for that purpose. I didn't post that
> patch because the notification on the root memcg's memory.oom_control in
> such conditions is currently being debated, so we need to solve that issue
> first.
--
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/