search for: oom_kil

...is trying to acquire lock: ffffffff8904ff60 (mmu_notifier_invalidate_range_start){+.+.}, at: __mmu_notifier_invalidate_range_end+0x0/0x360 mm/mmu_notifier.c:169 but task is already holding lock: ffffffff8904ff60 (mmu_notifier_invalidate_range_start){+.+.}, at: __oom_reap_task_mm+0x196/0x490 mm/oom_kill.c:542 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(mmu_notifier_invalidate_range_start); lock(mmu_notifier_invalidate_range_start); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by oom_reaper...

Hi All, I have a server that has its swappiness set to 0. It is running a little tight on memory and so there have been a couple of events where the OOM_killer has been invoked and killed off MySQL, which you would expect. Now if you have your swappiness at 0 then "A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone."[1] So even in this event should...

...ozzo.com [2] http://lkml.kernel.org/r/20160301181136-mutt-send-email-mst at redhat.com drivers/vhost/scsi.c | 2 +- drivers/vhost/vhost.c | 18 +++++++++--------- include/linux/sched.h | 1 + include/linux/uaccess.h | 22 ++++++++++++++++++++++ include/linux/uio.h | 10 ++++++++++ mm/oom_kill.c | 6 ++++++ 6 files changed, 49 insertions(+), 10 deletions(-) diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c index 0e6fd556c982..2c8dc0b9a21f 100644 --- a/drivers/vhost/scsi.c +++ b/drivers/vhost/scsi.c @@ -932,7 +932,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct...

...ozzo.com [2] http://lkml.kernel.org/r/20160301181136-mutt-send-email-mst at redhat.com drivers/vhost/scsi.c | 2 +- drivers/vhost/vhost.c | 18 +++++++++--------- include/linux/sched.h | 1 + include/linux/uaccess.h | 22 ++++++++++++++++++++++ include/linux/uio.h | 10 ++++++++++ mm/oom_kill.c | 6 ++++++ 6 files changed, 49 insertions(+), 10 deletions(-) diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c index 0e6fd556c982..2c8dc0b9a21f 100644 --- a/drivers/vhost/scsi.c +++ b/drivers/vhost/scsi.c @@ -932,7 +932,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct...

...rnel thread is created upon first register_oom_notifier() call. > Thus, those environments which do not use register_oom_notifier() will > not waste resource for the dedicated kernel thread. > > Signed-off-by: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> > --- > mm/oom_kill.c | 40 ++++++++++++++++++++++++++++++++++++---- > 1 file changed, 36 insertions(+), 4 deletions(-) > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index dee0f75..d9744f7 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -981,9 +981,37 @@ static void check_panic_on_oom...

...| 4 +-- drivers/vhost/vhost.c | 4 +-- fs/io-wq.c | 6 ++-- fs/io_uring.c | 6 ++-- include/linux/kthread.h | 4 +-- kernel/kthread.c | 33 +++++++++++----------- mm/oom_kill.c | 6 ++-- mm/vmacache.c | 4 +-- 11 files changed, 39 insertions(+), 40 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h index bce5e93fefc8..63db84e09408 100644 --- a/dri...

...| 4 +-- drivers/vhost/vhost.c | 4 +-- fs/io-wq.c | 6 ++-- fs/io_uring.c | 6 ++-- include/linux/kthread.h | 4 +-- kernel/kthread.c | 33 +++++++++++----------- mm/oom_kill.c | 6 ++-- mm/vmacache.c | 4 +-- 12 files changed, 41 insertions(+), 42 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h index b820c8fc689f..b063bd7f41d8 100644 --- a/dri...

...); > > + if (!ret && test_bit(MMF_UNSTABLE, &mm->flags)) > > + return -EFAULT; > > + return ret; And I've just noticed that this is not correct. We need if ((ret >= 0) && test_bit(MMF_UNSTABLE, &mm->flags)) [...] > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > > index 6303bc7caeda..3fa43e96a59b 100644 > > --- a/mm/oom_kill.c > > +++ b/mm/oom_kill.c > > @@ -506,6 +506,12 @@ static bool __oom_reap_task(struct task_struct *tsk) > > goto mm_drop; > > } > > > > + /* > > + * Tel...

...); > > + if (!ret && test_bit(MMF_UNSTABLE, &mm->flags)) > > + return -EFAULT; > > + return ret; And I've just noticed that this is not correct. We need if ((ret >= 0) && test_bit(MMF_UNSTABLE, &mm->flags)) [...] > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > > index 6303bc7caeda..3fa43e96a59b 100644 > > --- a/mm/oom_kill.c > > +++ b/mm/oom_kill.c > > @@ -506,6 +506,12 @@ static bool __oom_reap_task(struct task_struct *tsk) > > goto mm_drop; > > } > > > > + /* > > + * Tel...

.../r/20160301181136-mutt-send-email-mst at redhat.com > > drivers/vhost/scsi.c | 2 +- > drivers/vhost/vhost.c | 18 +++++++++--------- > include/linux/sched.h | 1 + > include/linux/uaccess.h | 22 ++++++++++++++++++++++ > include/linux/uio.h | 10 ++++++++++ > mm/oom_kill.c | 6 ++++++ > 6 files changed, 49 insertions(+), 10 deletions(-) > > diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c > index 0e6fd556c982..2c8dc0b9a21f 100644 > --- a/drivers/vhost/scsi.c > +++ b/drivers/vhost/scsi.c > @@ -932,7 +932,7 @@ vhost_scsi_hand...

...tPractices cheers -henrik On Fri, Feb 11, 2011 at 02:18:48PM +0300, George Shuklin wrote: > Yes, swap is almost mandatory - it will save machine from state ''very > low mem''. From my research (mostly on XCP) this state may cause > unstability for some kernels, causing OOM_killer to kill many processes > (sometimes including init - means kernel panic). Swap reducing chances > to get to this state. > > Second very important point: ballooning. When ballooning (inflating > balloon = reduce mem) occur, if kernel have no free address space it can > invo...

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

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

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API. Changes since v1: - drop a few patches - fix a comment typo - cover the newly merged use_mm/unuse_mm caller in vfio

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API. Changes since v1: - drop a few patches - fix a comment typo - cover the newly merged use_mm/unuse_mm caller in vfio

...=0x314 splash=silent desktop resume=/dev/hda1 showopts module (hd0,1)/boot/initrd-2.6.8-24.8-xen.gz Lowering the dom0_mem anything between 8192 to 13300 works, but then the kernel reboots during the boot process (for low values) and for higher values the boot script processes get killed by oom_kill, who eventually killes init too, kernel panics->reboot. Setting dom0_mem to 13313 or anything bigger doesn''t work, produces the error "Not enough memory for DOM0 memory reservation". What happens between 13300 and 13313 is untested, I think it has been narrowed down suffici...

https://bugzilla.mindrot.org/show_bug.cgi?id=1470 Summary: adjust Linux out-of-memory killer to stop sshd being killed Classification: Unclassified Product: Portable OpenSSH Version: 5.0p1 Platform: All URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=34176 7 OS/Version: Linux

On 09/16/2015 09:11 AM, Callum Scott wrote: > It is running a little > tight on memory and so there have been a couple of events where the > OOM_killer has been invoked and killed off MySQL, which you would expect. One thing that should be noted is that regardless of swappiness, overcommit might be an issue. If a single process is using most of the memory in a system, and attempts to fork(), as it will if it calls system(), then the system...