Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > > Does "that comment" refer to > > > > Elaborating the comment: the reason for the high wmark is to reduce > > the likelihood of livelocks and be sure to invoke the OOM killer, if > > we're still under pressure and reclaim just failed. The high wmark is > > used to

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > > Does "that comment" refer to > > > > Elaborating the comment: the reason for the high wmark is to reduce > > the likelihood of livelocks and be sure to invoke the OOM killer, if > > we're still under pressure and reclaim just failed. The high wmark is > > used to

Re: [PATCH 2/2] mm,oom: Use ALLOC_OOM for OOM victim's last second allocation.

Michal Hocko wrote: > On Wed 01-11-17 20:54:28, Tetsuo Handa wrote: > > Since commit 696453e66630ad45 ("mm, oom: task_will_free_mem should skip > > oom_reaped tasks") changed task_will_free_mem(current) in out_of_memory() > > to return false as soon as MMF_OOM_SK

Re: [PATCH 2/2] mm,oom: Use ALLOC_OOM for OOM victim's last second allocation.

Michal Hocko wrote: > On Wed 01-11-17 20:54:28, Tetsuo Handa wrote: > > Since commit 696453e66630ad45 ("mm, oom: task_will_free_mem should skip > > oom_reaped tasks") changed task_will_free_mem(current) in out_of_memory() > > to return false as soon as MMF_OOM_SK

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Wed 01-11-17 20:58:50, Tetsuo Handa wrote: > > > > But doing ALLOC_OOM for last second allocation attempt from > > > > out_of_memory() involve > > > > duplicating code (e.g. rebuilding zone list). > > > > > >

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Wed 01-11-17 20:58:50, Tetsuo Handa wrote: > > > > But doing ALLOC_OOM for last second allocation attempt from > > > > out_of_memory() involve > > > > duplicating code (e.g. rebuilding zone list). > > > > > >

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Tue 31-10-17 22:51:49, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote: > > > > >

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Tue 31-10-17 22:51:49, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote: > > > > >

[PATCH 2/2] mm,oom: Use ALLOC_OOM for OOM victim's last second allocation.

Reported-by: Manish Jaggi <mja...@caviumnetworks.com> Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Cc: Michal Hocko <mho...@suse.com> Cc: Oleg Nesterov <o...@redhat.com> Cc: Vladimir Davydov <vdavy...@virtuozzo.com> Cc: David Rientjes <rient...@google.c

[PATCH 2/2] mm,oom: Use ALLOC_OOM for OOM victim's last second allocation.

ed-by: Manish Jaggi Signed-off-by: Tetsuo Handa Cc: Michal Hocko Cc: Oleg Nesterov Cc: Vladimir Davydov Cc: David Rientjes --- mm/page_alloc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6654f52..382ed57 100644 --- a/mm/page_alloc.c +

[PATCH 1/2] mm,oom: Move last second allocation to inside the OOM killer.

expected to reduce the time window for potentially pre-mature OOM killing considerably, but this patch will cause last second allocation attempt always fail if out_of_memory() is not called. Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Suggested-by: Michal Hocko <mho...@su

[PATCH 1/2] mm,oom: Move last second allocation to inside the OOM killer.

expected to reduce the time window for potentially pre-mature OOM killing considerably, but this patch will cause last second allocation attempt always fail if out_of_memory() is not called. Signed-off-by: Tetsuo Handa Suggested-by: Michal Hocko --- include/linux/oom.h | 13 +++

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote: > > > > > While both have some merit, the first reason is mostly historical > > > > > because we have th

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote: > > > > > While both have some merit, the first reason is mostly historical > > > > > because we have th

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote: > > > While both have some merit, the first reason is mostly historical > > > because we have the explicit locking now and it is really unlikely that > > > the memory would be available right

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote: > > > While both have some merit, the first reason is mostly historical > > > because we have the explicit locking now and it is really unlikely that > > > the memory would be available right

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Tue 31-10-17 19:40:09, Tetsuo Handa wrote: > > The reason I used __alloc_pages_slowpath() in alloc_pages_before_oomkill() > > is > > to avoid duplicating code (such as checking for ALLOC_OOM and rebuilding > > zone > > list) whi

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

Michal Hocko wrote: > On Tue 31-10-17 19:40:09, Tetsuo Handa wrote: > > The reason I used __alloc_pages_slowpath() in alloc_pages_before_oomkill() > > is > > to avoid duplicating code (such as checking for ALLOC_OOM and rebuilding > > zone > > list) whi

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

.suse.cz [3] http://lkml.kernel.org/r/1503577106-9196-2-git-send-email-penguin-ker...@i-love.sakura.ne.jp [4] http://lkml.kernel.org/r/20170825080020.ge25...@dhcp22.suse.cz > > > + return get_page_from_freelist(gfp_mask, oc->order, alloc_flags, ac); > > +} > > +

Re: [PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

.suse.cz [3] http://lkml.kernel.org/r/1503577106-9196-2-git-send-email-penguin-ker...@i-love.sakura.ne.jp [4] http://lkml.kernel.org/r/20170825080020.ge25...@dhcp22.suse.cz > > > + return get_page_from_freelist(gfp_mask, oc->order, alloc_flags, ac); > > +} > > +

[PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

cation attempt after selecting an OOM victim will also help the OOM reaper to start reclaiming memory without waiting for oom_lock to be released. [1] http://lkml.kernel.org/r/20160128163802.ga15...@dhcp22.suse.cz [2] http://lkml.kernel.org/r/e6c83a26-1d59-4afd-55cf-04e58bdde...@caviumnetworks.co

[PATCH] mm,oom: Try last second allocation before and after selecting an OOM victim.

cation attempt after selecting an OOM victim will also help the OOM reaper to start reclaiming memory without waiting for oom_lock to be released. [1] http://lkml.kernel.org/r/20160128163802.ga15...@dhcp22.suse.cz [2] http://lkml.kernel.org/r/e6c83a26-1d59-4afd-55cf-04e58bdde...@caviumnetworks.co

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On 2017/10/26 16:49, Michal Hocko wrote: > On Wed 25-10-17 15:49:21, Greg Thelen wrote: >> Johannes Weiner wrote: >> >>> On Wed, Oct 25, 2017 at 09:00:57PM +0200, Michal Hocko wrote: > [...] So just to make it clear you would be OK with the retry on successful OOM

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On 2017/10/26 16:49, Michal Hocko wrote: > On Wed 25-10-17 15:49:21, Greg Thelen wrote: >> Johannes Weiner wrote: >> >>> On Wed, Oct 25, 2017 at 09:00:57PM +0200, Michal Hocko wrote: > [...] So just to make it clear you would be OK with the retry on successful OOM killer invocation and

[PATCH] mm: don't warn about allocations which stall for too long

remove warn_alloc(). [1] https://bugzilla.kernel.org/show_bug.cgi?id=192981 [2] http://lkml.kernel.org/r/cam_iqpwupvgc2ky8m-9yukects+zkjidasnymx7rmcbjbfy...@mail.gmail.com [3] commit db73ee0d46379922 ("mm, vmscan: do not loop on too_many_isolated for ever")) Signed-off-by: Tetsuo Handa <penguin-

[PATCH] mm: don't warn about allocations which stall for too long

remove warn_alloc(). [1] https://bugzilla.kernel.org/show_bug.cgi?id=192981 [2] http://lkml.kernel.org/r/cam_iqpwupvgc2ky8m-9yukects+zkjidasnymx7rmcbjbfy...@mail.gmail.com [3] commit db73ee0d46379922 ("mm, vmscan: do not loop on too_many_isolated for ever")) Signed-off-by: Tetsuo Handa Reported

Re: [PATCH] mm,page_alloc: Serialize out_of_memory() and allocation stall messages.

Tetsuo Handa wrote: > While warn_alloc() messages are completely unreadable, what we should note > are that > > (a) out_of_memory() => oom_kill_process() => dump_header() => show_mem() => > printk() > got stuck at console_unlock() despi

Re: [PATCH] mm,page_alloc: Serialize out_of_memory() and allocation stall messages.

Tetsuo Handa wrote: > While warn_alloc() messages are completely unreadable, what we should note > are that > > (a) out_of_memory() => oom_kill_process() => dump_header() => show_mem() => > printk() > got stuck at console_unlock() despi

Re: [PATCH] mm,page_alloc: Serialize out_of_memory() and allocation stall messages.

Tetsuo Handa wrote: > Michal Hocko wrote: > > Hell no! I've tried to be patient with you but it seems that is just > > pointless waste of time. Such an approach is absolutely not acceptable. > > You are adding an additional lock dependency into the picture. Say that > &

Re: [PATCH] mm,page_alloc: Serialize out_of_memory() and allocation stall messages.

Tetsuo Handa wrote: > Michal Hocko wrote: > > Hell no! I've tried to be patient with you but it seems that is just > > pointless waste of time. Such an approach is absolutely not acceptable. > > You are adding an additional lock dependency into the picture. Say that > &

Re: [PATCH v1 1/3] virtio-balloon: replace the coarse-grained balloon_lock

_info); > > If balloon_page_dequeue() can be concurrently called by both host's request > > and guest's OOM event, is (!dequeued_page) test in balloon_page_dequeue() > > safe? > > > I'm not sure about the question. The "dequeue_page" is a local variable > in the

Re: [PATCH v1 1/3] virtio-balloon: replace the coarse-grained balloon_lock

_info); > > If balloon_page_dequeue() can be concurrently called by both host's request > > and guest's OOM event, is (!dequeued_page) test in balloon_page_dequeue() > > safe? > > > I'm not sure about the question. The "dequeue_page" is a local variable > in the

Re: [PATCH v1 1/3] virtio-balloon: replace the coarse-grained balloon_lock

Wei Wang wrote: > The balloon_lock was used to synchronize the access demand to elements > of struct virtio_balloon and its queue operations (please see commit > e22504296d). This prevents the concurrent run of the leak_balloon and > fill_balloon functions, thereby resulting in a deadlock issue on

Re: [PATCH v1 1/3] virtio-balloon: replace the coarse-grained balloon_lock

Wei Wang wrote: > The balloon_lock was used to synchronize the access demand to elements > of struct virtio_balloon and its queue operations (please see commit > e22504296d). This prevents the concurrent run of the leak_balloon and > fill_balloon functions, thereby resulting in a deadlock issue on

Re: [PATCH v1 2/3] virtio-balloon: deflate up to oom_pages on OOM

Michael S. Tsirkin wrote: > On Fri, Oct 20, 2017 at 07:54:25PM +0800, Wei Wang wrote: > > The current implementation only deflates 256 pages even when a user > > specifies more than that via the oom_pages module param. This patch > > enables the deflating of up to oom_pages pages if there are

Re: [PATCH v1 2/3] virtio-balloon: deflate up to oom_pages on OOM

Michael S. Tsirkin wrote: > On Fri, Oct 20, 2017 at 07:54:25PM +0800, Wei Wang wrote: > > The current implementation only deflates 256 pages even when a user > > specifies more than that via the oom_pages module param. This patch > > enables the deflating of up to oom_pages pages if there are

Re: [PATCH 0/8] CaitSith LSM module

Tetsuo Handa wrote: > John Johansen wrote: > > On 05/20/2017 09:59 PM, Tetsuo Handa wrote: > > > John Johansen wrote: > > >> On 11/22/2016 10:31 PM, Tetsuo Handa wrote: > > >>> Tetsuo Handa wrote: > > >>>> John Johansen wrote: > &g

Re: [PATCH 0/8] CaitSith LSM module

Tetsuo Handa wrote: > John Johansen wrote: > > On 05/20/2017 09:59 PM, Tetsuo Handa wrote: > > > John Johansen wrote: > > >> On 11/22/2016 10:31 PM, Tetsuo Handa wrote: > > >>> Tetsuo Handa wrote: > > >>>> John Johansen wrote: > &g

Re: [PATCH] mm,page_alloc: Serialize out_of_memory() and allocation stall messages.

Michal Hocko wrote: > On Thu 19-10-17 19:51:02, Tetsuo Handa wrote: > > The printk() flooding problem caused by concurrent warn_alloc() calls was > > already pointed out by me, and there are reports of soft lockups caused by > > warn_alloc(). But this problem is left unhandle

Re: [PATCH] mm,page_alloc: Serialize out_of_memory() and allocation stall messages.

Michal Hocko wrote: > On Thu 19-10-17 19:51:02, Tetsuo Handa wrote: > > The printk() flooding problem caused by concurrent warn_alloc() calls was > > already pointed out by me, and there are reports of soft lockups caused by > > warn_alloc(). But this problem is left unhandle

Re: [PATCH] tomoyo: fix timestamping for y2038

yo/util.c @@ -96,7 +96,7 @@ void tomoyo_convert_time(time64_t time64, struct tomoyo_time *stamp) stamp->hour = tm.tm_hour; stamp->day = tm.tm_mday; stamp->month = tm.tm_mon + 1; - stamp->year = tm.tm_year - (1970 - 1900); + stamp->year = tm.tm_year + 1900; } /** Then, you can add Acked-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>

Re: [PATCH] tomoyo: fix timestamping for y2038

+96,7 @@ void tomoyo_convert_time(time64_t time64, struct tomoyo_time *stamp) stamp->hour = tm.tm_hour; stamp->day = tm.tm_mday; stamp->month = tm.tm_mon + 1; - stamp->year = tm.tm_year - (1970 - 1900); + stamp->year = tm.tm_year + 1900; } /** Then, you can add Acked-by: Tetsuo Handa

[PATCH] mm,page_alloc: Serialize out_of_memory() and allocation stall messages.

s because Michal does not like serialization. Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Reported-by: Cong Wang <xiyou.wangc...@gmail.com> Reported-by: yuwang.yuwang <yuwang.yuw...@alibaba-inc.com> Reported-by: Johannes Weiner <han...@cmpxchg.org> Cc: Serg

[PATCH] mm,page_alloc: Serialize out_of_memory() and allocation stall messages.

s because Michal does not like serialization. Signed-off-by: Tetsuo Handa Reported-by: Cong Wang Reported-by: yuwang.yuwang Reported-by: Johannes Weiner Cc: Sergey Senozhatsky Cc: Petr Mladek Cc: Michal Hocko --- include/linux/oom.h | 1 + mm/oom_kill.c | 5 + mm/page_alloc.c | 4 +++-

Re: [PATCH] virtio_balloon: fix deadlock on OOM

Michael S. Tsirkin wrote: > This is a replacement for > [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify() > but unlike that patch it actually deflates on oom even in presence of > lock contention. But Wei Wang is proposing VIRTIO_BALLOON_F_SG which will try to allocate

Re: [PATCH] virtio_balloon: fix deadlock on OOM

Michael S. Tsirkin wrote: > This is a replacement for > [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify() > but unlike that patch it actually deflates on oom even in presence of > lock contention. But Wei Wang is proposing VIRTIO_BALLOON_F_SG which will try to allocate

Re: [PATCH] vmalloc: back off only when the current task is OOM killed

Michal Hocko wrote: > On Tue 10-10-17 21:47:02, Tetsuo Handa wrote: > > I think that massive vmalloc() consumers should be (as well as massive > > alloc_page() consumers) careful such that they will be chosen as first OOM > > victim, for vmalloc() does not abort as

Re: [PATCH] vmalloc: back off only when the current task is OOM killed

Michal Hocko wrote: > On Tue 10-10-17 21:47:02, Tetsuo Handa wrote: > > I think that massive vmalloc() consumers should be (as well as massive > > alloc_page() consumers) careful such that they will be chosen as first OOM > > victim, for vmalloc() does not abort as

Re: [PATCH v16 3/5] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > > And even if we could remove balloon_lock, you still cannot use > > __GFP_DIRECT_RECLAIM at xb_set_page(). I think you will need to use > > "whether it is safe to wait" flag from > > "[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()" . > > Without the lock

Re: [PATCH v16 3/5] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > > And even if we could remove balloon_lock, you still cannot use > > __GFP_DIRECT_RECLAIM at xb_set_page(). I think you will need to use > > "whether it is safe to wait" flag from > > "[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()" . > > Without the lock

Re: [PATCH] vmalloc: back off only when the current task is OOM killed

Michal Hocko wrote: > On Tue 10-10-17 19:58:53, Tetsuo Handa wrote: > > Commit 5d17a73a2ebeb8d1 ("vmalloc: back off when the current task is > > killed") revealed two bugs [1] [2] that were not ready to fail vmalloc() > > upon SIGKILL. But since the intent of tha

Re: [PATCH] vmalloc: back off only when the current task is OOM killed

Michal Hocko wrote: > On Tue 10-10-17 19:58:53, Tetsuo Handa wrote: > > Commit 5d17a73a2ebeb8d1 ("vmalloc: back off when the current task is > > killed") revealed two bugs [1] [2] that were not ready to fail vmalloc() > > upon SIGKILL. But since the intent of tha

Re: [PATCH v16 3/5] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > On 10/09/2017 11:20 PM, Michael S. Tsirkin wrote: > > On Sat, Sep 30, 2017 at 12:05:52PM +0800, Wei Wang wrote: > >> +static inline void xb_set_page(struct virtio_balloon *vb, > >> + struct page *page, > >> + unsigned long *pfn_min,

Re: [PATCH v16 3/5] virtio-balloon: VIRTIO_BALLOON_F_SG

Wei Wang wrote: > On 10/09/2017 11:20 PM, Michael S. Tsirkin wrote: > > On Sat, Sep 30, 2017 at 12:05:52PM +0800, Wei Wang wrote: > >> +static inline void xb_set_page(struct virtio_balloon *vb, > >> + struct page *page, > >> + unsigned long *pfn_min,

[PATCH] vmalloc: back off only when the current task is OOM killed

/20171003225504.ga...@cmpxchg.org Fixes: 5d17a73a2ebeb8d1 ("vmalloc: back off when the current task is killed") Cc: stable # 4.11+ Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> --- mm/vmalloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/vmalloc

[PATCH] vmalloc: back off only when the current task is OOM killed

/20171003225504.ga...@cmpxchg.org Fixes: 5d17a73a2ebeb8d1 ("vmalloc: back off when the current task is killed") Cc: stable # 4.11+ Signed-off-by: Tetsuo Handa --- mm/vmalloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 8a43db6..6add29d 100

Re: [PATCH v16 1/5] lib/xbitmap: Introduce xbitmap

On 2017/09/30 13:05, Wei Wang wrote: > /** > + * xb_preload - preload for xb_set_bit() > + * @gfp_mask: allocation mask to use for preloading > + * > + * Preallocate memory to use for the next call to xb_set_bit(). This function > + * returns with preemption disabled. It will be enabled by

Re: [PATCH v16 1/5] lib/xbitmap: Introduce xbitmap

On 2017/09/30 13:05, Wei Wang wrote: > /** > + * xb_preload - preload for xb_set_bit() > + * @gfp_mask: allocation mask to use for preloading > + * > + * Preallocate memory to use for the next call to xb_set_bit(). This function > + * returns with preemption disabled. It will be enabled by

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

Michal Hocko wrote: > On Sat 07-10-17 13:05:24, Tetsuo Handa wrote: > > Johannes Weiner wrote: > > > On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote: > > > > On 2017/10/05 19:36, Tetsuo Handa wrote: > > > > > I don't want this patch back

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

Michal Hocko wrote: > On Sat 07-10-17 13:05:24, Tetsuo Handa wrote: > > Johannes Weiner wrote: > > > On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote: > > > > On 2017/10/05 19:36, Tetsuo Handa wrote: > > > > > I don't want this patch back

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

Johannes Weiner wrote: > On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote: > > On 2017/10/05 19:36, Tetsuo Handa wrote: > > > I don't want this patch backported. If you want to backport, > > > "s/fatal_signal_pending/tsk_is_oom_victim/" is th

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

Johannes Weiner wrote: > On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote: > > On 2017/10/05 19:36, Tetsuo Handa wrote: > > > I don't want this patch backported. If you want to backport, > > > "s/fatal_signal_pending/tsk_is_oom_victim/" is th

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

On 2017/10/05 19:36, Tetsuo Handa wrote: > I don't want this patch backported. If you want to backport, > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way. If you backport this patch, you will see "complete depletion of memory reserves" and "extra OOM k

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

On 2017/10/05 19:36, Tetsuo Handa wrote: > I don't want this patch backported. If you want to backport, > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way. If you backport this patch, you will see "complete depletion of memory reserves" and "extra OOM k

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

Josh Poimboeuf wrote: > On Wed, Oct 04, 2017 at 06:44:50AM +0900, Tetsuo Handa wrote: > > Josh Poimboeuf wrote: > > > On Tue, Oct 03, 2017 at 11:28:15AM -0500, Josh Poimboeuf wrote: > > > > There are two bugs: > > > > > > > > 1) Somebody -

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

Josh Poimboeuf wrote: > On Wed, Oct 04, 2017 at 06:44:50AM +0900, Tetsuo Handa wrote: > > Josh Poimboeuf wrote: > > > On Tue, Oct 03, 2017 at 11:28:15AM -0500, Josh Poimboeuf wrote: > > > > There are two bugs: > > > > > > > > 1) Somebody -

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

On 2017/10/05 16:57, Michal Hocko wrote: > On Wed 04-10-17 19:18:21, Johannes Weiner wrote: >> On Wed, Oct 04, 2017 at 03:32:45PM -0700, Andrew Morton wrote: > [...] >>> You don't think they should be backported into -stables? >> >> Good point. For this one, it makes sense to CC stable, for 4.11

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

On 2017/10/05 16:57, Michal Hocko wrote: > On Wed 04-10-17 19:18:21, Johannes Weiner wrote: >> On Wed, Oct 04, 2017 at 03:32:45PM -0700, Andrew Morton wrote: > [...] >>> You don't think they should be backported into -stables? >> >> Good point. For this one, it makes sense to CC stable, for 4.11

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

Johannes Weiner wrote: > On Thu, Oct 05, 2017 at 05:49:43AM +0900, Tetsuo Handa wrote: > > On 2017/10/05 3:59, Johannes Weiner wrote: > > > But the justification to make that vmalloc() call fail like this isn't > > > convincing, either. The patch mentions an OOM victim

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

Johannes Weiner wrote: > On Thu, Oct 05, 2017 at 05:49:43AM +0900, Tetsuo Handa wrote: > > On 2017/10/05 3:59, Johannes Weiner wrote: > > > But the justification to make that vmalloc() call fail like this isn't > > > convincing, either. The patch mentions an OOM victim

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

On 2017/10/05 3:59, Johannes Weiner wrote: > But the justification to make that vmalloc() call fail like this isn't > convincing, either. The patch mentions an OOM victim exhausting the > memory reserves and thus deadlocking the machine. But the OOM killer > is only one, improbable source of fatal

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

On 2017/10/05 3:59, Johannes Weiner wrote: > But the justification to make that vmalloc() call fail like this isn't > convincing, either. The patch mentions an OOM victim exhausting the > memory reserves and thus deadlocking the machine. But the OOM killer > is only one, improbable source of fatal

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

Josh Poimboeuf wrote: > On Tue, Oct 03, 2017 at 11:28:15AM -0500, Josh Poimboeuf wrote: > > There are two bugs: > > > > 1) Somebody -- presumably lockdep -- is corrupting the stack. Need the > >lockdep people to look at that. > > > > 2) The 32-bit FP unwinder isn't handling the corrupt

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

Josh Poimboeuf wrote: > On Tue, Oct 03, 2017 at 11:28:15AM -0500, Josh Poimboeuf wrote: > > There are two bugs: > > > > 1) Somebody -- presumably lockdep -- is corrupting the stack. Need the > >lockdep people to look at that. > > > > 2) The 32-bit FP unwinder isn't handling the corrupt

Re: [4.14-rc1 x86] WARNING: kernel stack regs at f60bbb12 in swapper:1 has bad 'bp' value 0ba00000

Josh Poimboeuf wrote: > On Tue, Oct 03, 2017 at 09:35:18AM -0500, Josh Poimboeuf wrote: > > On Tue, Oct 03, 2017 at 10:44:13PM +0900, Tetsuo Handa wrote: > > > Josh Poimboeuf wrote: > > > > > > > On Tue, Oct 03, 2017 at 12:37:44PM +0200, Borislav Petkov wrot

Re: [4.14-rc1 x86] WARNING: kernel stack regs at f60bbb12 in swapper:1 has bad 'bp' value 0ba00000

Josh Poimboeuf wrote: > On Tue, Oct 03, 2017 at 09:35:18AM -0500, Josh Poimboeuf wrote: > > On Tue, Oct 03, 2017 at 10:44:13PM +0900, Tetsuo Handa wrote: > > > Josh Poimboeuf wrote: > > > > > > > On Tue, Oct 03, 2017 at 12:37:44PM +0200, Borislav Petkov wrot

Re: [4.14-rc1 x86] WARNING: kernel stack regs at f60bbb12 in swapper:1 has bad 'bp' value 0ba00000

Josh Poimboeuf wrote: > On Tue, Oct 03, 2017 at 10:44:13PM +0900, Tetsuo Handa wrote: > > Josh Poimboeuf wrote: > > > > > On Tue, Oct 03, 2017 at 12:37:44PM +0200, Borislav Petkov wrote: > > > > On Tue, Oct 03, 2017 at 07:29:36PM +0900, Tetsuo Handa

Re: [4.14-rc1 x86] WARNING: kernel stack regs at f60bbb12 in swapper:1 has bad 'bp' value 0ba00000

Josh Poimboeuf wrote: > On Tue, Oct 03, 2017 at 10:44:13PM +0900, Tetsuo Handa wrote: > > Josh Poimboeuf wrote: > > > > > On Tue, Oct 03, 2017 at 12:37:44PM +0200, Borislav Petkov wrote: > > > > On Tue, Oct 03, 2017 at 07:29:36PM +0900, Tetsuo Handa

Re: [4.14-rc1 x86] WARNING: kernel stack regs at f60bbb12 inswapper:1 has bad 'bp' value 0ba00000

Josh Poimboeuf wrote: > On Tue, Oct 03, 2017 at 12:37:44PM +0200, Borislav Petkov wrote: > > On Tue, Oct 03, 2017 at 07:29:36PM +0900, Tetsuo Handa wrote: > > > Tetsuo Handa wrote: > > > > Tetsuo Handa wrote: > > > > > Tetsuo Handa wrot

Re: [4.14-rc1 x86] WARNING: kernel stack regs at f60bbb12 inswapper:1 has bad 'bp' value 0ba00000

Josh Poimboeuf wrote: > On Tue, Oct 03, 2017 at 12:37:44PM +0200, Borislav Petkov wrote: > > On Tue, Oct 03, 2017 at 07:29:36PM +0900, Tetsuo Handa wrote: > > > Tetsuo Handa wrote: > > > > Tetsuo Handa wrote: > > > > > Tetsuo Handa wrot

Re: [4.14-rc1 x86] WARNING: kernel stack regs at f60bbb12 in swapper:1 has bad 'bp' value 0ba00000

Tetsuo Handa wrote: > Tetsuo Handa wrote: > > Tetsuo Handa wrote: > > > I'm seeing below error between > > > 4898b99c261efe32 ("Merge tag 'acpi-4.13-rc7' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm") (git > > > bis

Re: [4.14-rc1 x86] WARNING: kernel stack regs at f60bbb12 in swapper:1 has bad 'bp' value 0ba00000

Tetsuo Handa wrote: > Tetsuo Handa wrote: > > Tetsuo Handa wrote: > > > I'm seeing below error between > > > 4898b99c261efe32 ("Merge tag 'acpi-4.13-rc7' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm") (git > > > bis

Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

Michal Hocko wrote: > On Sun 01-10-17 12:26:47, Pavel Machek wrote: > > Hi! > > > > > I inserted u-SD card, only to realize that it is not detected as it > > > should be. And dmesg indeed reveals: > > > > Tetsuo asked me to report this to linux-mm. > > > > But 2^4 is 16 pages, IIRC that can't

Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

Michal Hocko wrote: > On Sun 01-10-17 12:26:47, Pavel Machek wrote: > > Hi! > > > > > I inserted u-SD card, only to realize that it is not detected as it > > > should be. And dmesg indeed reveals: > > > > Tetsuo asked me to report this to linux-mm. > > > > But 2^4 is 16 pages, IIRC that can't

Re: [v8 0/4] cgroup-aware OOM killer

Shakeel Butt wrote: > I think Tim has given very clear explanation why comparing A & D makes > perfect sense. However I think the above example, a single user system > where a user has designed and created the whole hierarchy and then > attaches different jobs/applications to different nodes in

Re: [v8 0/4] cgroup-aware OOM killer

Shakeel Butt wrote: > I think Tim has given very clear explanation why comparing A & D makes > perfect sense. However I think the above example, a single user system > where a user has designed and created the whole hierarchy and then > attaches different jobs/applications to different nodes in

Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

Pavel Machek wrote: > Hi! > > > I inserted u-SD card, only to realize that it is not detected as it > > should be. And dmesg indeed reveals: > > Tetsuo asked me to report this to linux-mm. > > But 2^4 is 16 pages, IIRC that can't be expected to work reliably, and > thus this sounds like MMC

Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

Pavel Machek wrote: > Hi! > > > I inserted u-SD card, only to realize that it is not detected as it > > should be. And dmesg indeed reveals: > > Tetsuo asked me to report this to linux-mm. > > But 2^4 is 16 pages, IIRC that can't be expected to work reliably, and > thus this sounds like MMC

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

Yang Shi wrote: > On 9/28/17 1:45 PM, Tetsuo Handa wrote: > > Yang Shi wrote: > >> On 9/28/17 12:57 PM, Tetsuo Handa wrote: > >>> Yang Shi wrote: > >>>> On 9/27/17 9:36 PM, Tetsuo Handa wrote: > >>>>> On 2017/09/28 6:46, Yang Shi

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

Yang Shi wrote: > On 9/28/17 1:45 PM, Tetsuo Handa wrote: > > Yang Shi wrote: > >> On 9/28/17 12:57 PM, Tetsuo Handa wrote: > >>> Yang Shi wrote: > >>>> On 9/27/17 9:36 PM, Tetsuo Handa wrote: > >>>>> On 2017/09/28 6:46, Yang Shi

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

Yang Shi wrote: > On 9/28/17 12:57 PM, Tetsuo Handa wrote: > > Yang Shi wrote: > >> On 9/27/17 9:36 PM, Tetsuo Handa wrote: > >>> On 2017/09/28 6:46, Yang Shi wrote: > >>>> Changelog v7 -> v8: > >>>> * Adopted Michal’s suggestion to d

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

Yang Shi wrote: > On 9/28/17 12:57 PM, Tetsuo Handa wrote: > > Yang Shi wrote: > >> On 9/27/17 9:36 PM, Tetsuo Handa wrote: > >>> On 2017/09/28 6:46, Yang Shi wrote: > >>>> Changelog v7 -> v8: > >>>> * Adopted Michal’s suggestion to d

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

Yang Shi wrote: > On 9/27/17 9:36 PM, Tetsuo Handa wrote: > > On 2017/09/28 6:46, Yang Shi wrote: > >> Changelog v7 -> v8: > >> * Adopted Michal’s suggestion to dump unreclaim slab info when > >> unreclaimable slabs amount > total user memory. No

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

Yang Shi wrote: > On 9/27/17 9:36 PM, Tetsuo Handa wrote: > > On 2017/09/28 6:46, Yang Shi wrote: > >> Changelog v7 -> v8: > >> * Adopted Michal’s suggestion to dump unreclaim slab info when > >> unreclaimable slabs amount > total user memory. No

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

On 2017/09/28 6:46, Yang Shi wrote: > Changelog v7 —> v8: > * Adopted Michal’s suggestion to dump unreclaim slab info when unreclaimable > slabs amount > total user memory. Not only in oom panic path. Holding slab_mutex inside dump_unreclaimable_slab() was refrained since V2 because there are

Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message

On 2017/09/28 6:46, Yang Shi wrote: > Changelog v7 —> v8: > * Adopted Michal’s suggestion to dump unreclaim slab info when unreclaimable > slabs amount > total user memory. Not only in oom panic path. Holding slab_mutex inside dump_unreclaimable_slab() was refrained since V2 because there are

Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when kernel panic

On 2017/09/15 2:14, Yang Shi wrote: > @@ -1274,6 +1276,29 @@ static int slab_show(struct seq_file *m, void *p) > return 0; > } > > +void show_unreclaimable_slab() > +{ > + struct kmem_cache *s = NULL; > + struct slabinfo sinfo; > + > + memset(, 0, sizeof(sinfo)); > + > +

Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when kernel panic

On 2017/09/15 2:14, Yang Shi wrote: > @@ -1274,6 +1276,29 @@ static int slab_show(struct seq_file *m, void *p) > return 0; > } > > +void show_unreclaimable_slab() > +{ > + struct kmem_cache *s = NULL; > + struct slabinfo sinfo; > + > + memset(, 0, sizeof(sinfo)); > + > +

Re: [PATCH] mm: respect the __GFP_NOWARN flag when warning about stalls

Vlastimil Babka wrote: > On 09/13/2017 03:54 PM, Tetsuo Handa wrote: > > Michal Hocko wrote: > >> Let's see what others think about this. > > > > Whether __GFP_NOWARN should warn about stalls is not a topic to discuss. > > It is the topic of this threa

Re: [PATCH] mm: respect the __GFP_NOWARN flag when warning about stalls

Vlastimil Babka wrote: > On 09/13/2017 03:54 PM, Tetsuo Handa wrote: > > Michal Hocko wrote: > >> Let's see what others think about this. > > > > Whether __GFP_NOWARN should warn about stalls is not a topic to discuss. > > It is the topic of this threa

<    13   14   15   16   17   18   19   20   21   22   >