On Mon, May 4, 2020 at 9:06 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > On Mon 04-05-20 08:35:57, Shakeel Butt wrote: > > On Mon, May 4, 2020 at 8:00 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > > > On Mon 04-05-20 07:53:01, Shakeel Butt wrote: > [...] > > > > I am trying to see if "no eligible task" is really an issue and should > > > > be warned for the "other use cases". The only real use-case I can > > > > think of are resource managers adjusting the limit dynamically. I > > > > don't see "no eligible task" a concerning reason for such use-case. > > > > > > It is very much a concerning reason to notify about like any other OOM > > > situation due to hard limit breach. In this case it is worse in some > > > sense because the limit cannot be trimmed down because there is no > > > directly reclaimable memory at all. Such an oom situation is > > > effectivelly conserved. > > > -- > > > > Let me make a more precise statement and tell me if you agree. The "no > > eligible task" is concerning for the charging path but not for the > > writer of memory.max. The writer can read the usage and > > cgroup.[procs|events] to figure out the situation if needed. > > I really hate to repeat myself but this is no different from a regular > oom situation. Conceptually yes there is no difference but there is no *divine restriction* to not make a difference if there is a real world use-case which would benefit from it. > Admin sets the hard limit and the kernel tries to act > upon that. > > You cannot make any assumption about what admin wanted or didn't want > to see. Actually we always make assumptions on how the feature we implement will be used and as new use-cases come the assumptions evolve. > We simply trigger the oom killer on memory.max and this is a > documented behavior. No eligible task or no task at all is a simply a > corner case For "sweep before tear down" use-case this is not a corner case. > when the kernel cannot act and mentions that along with the > oom report so that whoever consumes that information can debug or act on > that fact. > > Silencing the oom report is simply removing a potentially useful > aid to debug further a potential problem. *Potentially* useful for debugging versus actually beneficial for "sweep before tear down" use-case. Also I am not saying to make "no dumps for memory.max when no eligible tasks" a set in stone rule. We can always reevaluate when such information will actually be useful. Johannes/Andrew, what's your opinion?
