On Thu, 9 Jan 2014, Andrew Morton wrote:
> > > It was dropped because the other memcg developers disagreed with it.
> > >
> >
> > It was acked-by Michal.
>
> And Johannes?
>
Johannes is arguing for the same semantics that VMPRESSURE_CRITICAL and/or
memory thresholds provides, which disagrees from the list of solutions
that Documentation/cgroups/memory.txt gives for userspace oom handler
wakeups and is required for any sane implementation.
> > We REQUIRE this behavior for a sane userspace oom handler implementation.
> > You've snipped my email quite extensively, but I'd like to know
> > specifically how you would implement a userspace oom handler described by
> > Section 10 of Documentation/cgroups/memory.txt without this patch?
>
> From long experience I know that if I suggest an alternative
> implementation, advocates of the initial implementation will invest
> great effort in demonstrating why my suggestion won't work while
> investing zero effort in thinking up alternatives themselves.
>
Easy thing to say when you don't suggest an alternative implementation,
right?
I'm fully aware that I'm the only one in this thread who is charged with
writing and maintaining userspace oom handlers, so I'm not asking for an
actual implementation, but rather an answer to the very simple question:
how does userspace know whether it needs to actually do anything or not
without this patch?
> So the interface is wrong. We have two semantically different kernel
> states which are being communicated to userspace in the same way, so
> userspace cannot disambiguate.
>
We want to notify on one state, which is what is described in
Documentation/cgroups/memory.txt and works with my patch, and not notify
on another state which was broken by ME in f9434ad15524 ("memcg: give
current access to memory reserves if it's trying to die"). Am I allowed
to fix my own breakage?
Userspace expects to get notified for the reasons listed in the
documentation, not when the kernel is going to allow memory to be freed
itself. You can get notification of oom through vmpressure or memory
thresholds, memory.oom_control needs to be reserved for situations when
"something" needs to be done by userspace and as defined by the
documentation.
> Solution: invent a better communication scheme with a richer payload.
> Use that, deprecate the old interface if poss.
>
There are better communication schemes for oom conditions that are not
actionable, they are memcg memory threshold notifications and vmpressure.
> Johannes' final email in this thread has yet to be replied to, btw.
>
Will do.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>