search for: oom_control

...++++++++++++++++++++++++++++++++++++---- > 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(struct oom_control *oc, > } > > static BLOCKING_NOTIFIER_HEAD(oom_notify_list); > +static bool oom_notifier_requested; > +static unsigned long oom_notifier_freed; > +static struct task_struct *oom_notifier_th; > +static DECLARE_WAIT_QUEUE_HEAD(oom_notifier_request_wait); > +static DECLARE_...

I have 3.10 kernel. I am running some data processing job, need to first copy big (>5 GB) input files. The jobs were killed, because the system thought I used 5 GB memory from the file copying. On Fri, Mar 10, 2017 at 3:04 PM, David Both <dboth at millennium-technology.com > wrote: > First - why in the world would you want to disable kernel memory > accounting? I don't think

...pying. If you?re using ?cp? you probably aren?t using 5G of RAM. That?s not how ?cp? works. Actual errors might be helpful here. If you are running batch processing and don?t want the OOM Killer to ever get involved, the cgroup memory accounting features actually let you turn it off with memory.oom_control=1 in the cgroup. You can also turn off the heuristic overcommit memory manager (see https://www.kernel.org/doc/Documentation/vm/overcommit-accounting for details) but I suggest figuring out your problem with copying files first. -- Jonathan Billings <billings at negate.org>

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

...ot 0 Sep 15 17:14 memory.memsw.max_usage_in_bytes -r--r--r-- 1 root root 0 Sep 15 17:14 memory.memsw.usage_in_bytes -rw-r--r-- 1 root root 0 Sep 15 17:14 memory.move_charge_at_immigrate -r--r--r-- 1 root root 0 Sep 15 17:14 memory.numa_stat -rw-r--r-- 1 root root 0 Sep 15 17:14 memory.oom_control ---------- 1 root root 0 Sep 15 17:14 memory.pressure_level -rw-r--r-- 1 root root 0 Sep 15 17:14 memory.soft_limit_in_bytes -r--r--r-- 1 root root 0 Sep 15 17:14 memory.stat -rw-r--r-- 1 root root 0 Sep 15 17:14 memory.swappiness -r--r--r-- 1 root root 0 Sep 15 17:14 memory.usage_in...

...SYMBOL_GPL(unuse_mm); +EXPORT_SYMBOL_GPL(kthread_unuse_mm); #ifdef CONFIG_BLK_CGROUP /** diff --git a/mm/oom_kill.c b/mm/oom_kill.c index dfc357614e56..958d2972313f 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -126,7 +126,7 @@ static bool oom_cpuset_eligible(struct task_struct *tsk, struct oom_control *oc) /* * The process p may have detached its own ->mm while exiting or through - * use_mm(), but one or more of its subthreads may still have a valid + * kthread_use_mm(), but one or more of its subthreads may still have a valid * pointer. Return p, or any of its subthreads with a valid...

...SYMBOL_GPL(unuse_mm); +EXPORT_SYMBOL_GPL(kthread_unuse_mm); #ifdef CONFIG_BLK_CGROUP /** diff --git a/mm/oom_kill.c b/mm/oom_kill.c index dfc357614e56..958d2972313f 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -126,7 +126,7 @@ static bool oom_cpuset_eligible(struct task_struct *tsk, struct oom_control *oc) /* * The process p may have detached its own ->mm while exiting or through - * use_mm(), but one or more of its subthreads may still have a valid + * kthread_use_mm(), but one or more of its subthreads may still have a valid * pointer. Return p, or any of its subthreads with a valid...

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