Displaying 3 results from an estimated 3 matches for "is_memcg_oom".
2017 Oct 02
0
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
...33,21 @@ int unregister_oom_notifier(struct notifier_block *nb)
> */
> bool out_of_memory(struct oom_control *oc)
> {
> - unsigned long freed = 0;
> enum oom_constraint constraint = CONSTRAINT_NONE;
>
> if (oom_killer_disabled)
> return false;
>
> - if (!is_memcg_oom(oc)) {
> - blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
> - if (freed > 0)
> + if (!is_memcg_oom(oc) && oom_notifier_th) {
> + oom_notifier_requested = true;
> + wake_up(&oom_notifier_request_wait);
> + wait_event_timeout(oom_notifier_resp...
2017 Sep 11
6
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
Hello.
I noticed that virtio_balloon is using register_oom_notifier() and
leak_balloon() from virtballoon_oom_notify() might depend on
__GFP_DIRECT_RECLAIM memory allocation.
In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to
serialize against fill_balloon(). But in fill_balloon(),
alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
called with
2017 Sep 11
6
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
Hello.
I noticed that virtio_balloon is using register_oom_notifier() and
leak_balloon() from virtballoon_oom_notify() might depend on
__GFP_DIRECT_RECLAIM memory allocation.
In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to
serialize against fill_balloon(). But in fill_balloon(),
alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
called with