lkml.org 
[lkml]   [2018]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] mm, hugetlb_cgroup: suppress SIGBUS when hugetlb_cgroup charge fails
On Fri 25-05-18 15:18:11, David Rientjes wrote:
[...]
> Let's see what Mike and Aneesh say, because they may object to using
> VM_FAULT_OOM because there's no way to guarantee that we'll come under the
> limit of hugetlb_cgroup as a result of the oom. My assumption is that we
> use VM_FAULT_SIGBUS since oom killing will not guarantee that the
> allocation can succeed.

Yes. And the lack of hugetlb awareness in the oom killer is another
reason. There is absolutely no reason to kill a task when somebody
misconfigured the hugetlb pool.

> But now a process can get a SIGBUS if its hugetlb
> pages are not allocatable or its under a limit imposed by hugetlb_cgroup
> that it's not aware of. Faulting hugetlb pages is certainly risky
> business these days...

It's always been and I am afraid it will always be unless somebody
simply reimplements the current code to be NUMA aware for example (it is
just too easy to drain a per NODE reserves...).

> Perhaps the optimal solution for reaching hugetlb_cgroup limits is to
> induce an oom kill from within the hugetlb_cgroup itself? Otherwise the
> unlucky process to fault their hugetlb pages last gets SIGBUS.

Hmm, so you expect that the killed task would simply return pages to the
pool? Wouldn't that require to have a hugetlb cgroup OOM killer that
would only care about hugetlb reservations of tasks? Is that worth all
the effort and the additional code?
--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2018-05-28 17:59    [W:0.418 / U:0.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site