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

Michal Hocko wrote: > On Thu 09-11-17 10:34:46, peter enderborg wrote: > > On 11/09/2017 09:52 AM, Michal Hocko wrote: > > > I am not sure. I would rather see a tracepoint to mark the allocator > > > entry. This would allow both 1) measuring the allocation latency (to > > > compare it to the

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

Michal Hocko wrote: > On Thu 09-11-17 10:34:46, peter enderborg wrote: > > On 11/09/2017 09:52 AM, Michal Hocko wrote: > > > I am not sure. I would rather see a tracepoint to mark the allocator > > > entry. This would allow both 1) measuring the allocation latency (to > > > compare it to the

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

On Thu 09-11-17 10:34:46, peter enderborg wrote: > On 11/09/2017 09:52 AM, Michal Hocko wrote: > > I am not sure. I would rather see a tracepoint to mark the allocator > > entry. This would allow both 1) measuring the allocation latency (to > > compare it to the trace_mm_page_alloc and 2) check

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

On Thu 09-11-17 10:34:46, peter enderborg wrote: > On 11/09/2017 09:52 AM, Michal Hocko wrote: > > I am not sure. I would rather see a tracepoint to mark the allocator > > entry. This would allow both 1) measuring the allocation latency (to > > compare it to the trace_mm_page_alloc and 2) check

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

[Please try to trim the context you are replying to] On Wed 08-11-17 11:30:23, peter enderborg wrote: [...] > What about the idea to keep the function, but instead of printing only do a > trace event. I am not sure. I would rather see a tracepoint to mark the allocator entry. This would allow

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

[Please try to trim the context you are replying to] On Wed 08-11-17 11:30:23, peter enderborg wrote: [...] > What about the idea to keep the function, but instead of printing only do a > trace event. I am not sure. I would rather see a tracepoint to mark the allocator entry. This would allow

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

Hi Tetsuo, Can you see if this patch helps your situation? OK, for the rest of you. Let's have the showdown ;-) This patch implements what I discussed in Kernel Summit. I added lockdep annotation (hopefully correctly), and it hasn't had any splats (since I fixed some bugs in the first

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

Hi Tetsuo, Can you see if this patch helps your situation? OK, for the rest of you. Let's have the showdown ;-) This patch implements what I discussed in Kernel Summit. I added lockdep annotation (hopefully correctly), and it hasn't had any splats (since I fixed some bugs in the first

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

On Thu, 2 Nov 2017 17:53:13 +0900 Sergey Senozhatsky wrote: > On (10/31/17 15:32), Steven Rostedt wrote: > [..] > > (new globals) > > static DEFINE_SPIN_LOCK(console_owner_lock); > > static struct task_struct console_owner; > > static bool waiter; > > > >

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

On Thu, 2 Nov 2017 17:53:13 +0900 Sergey Senozhatsky wrote: > On (10/31/17 15:32), Steven Rostedt wrote: > [..] > > (new globals) > > static DEFINE_SPIN_LOCK(console_owner_lock); > > static struct task_struct console_owner; > > static bool waiter; > > > > console_unlock() { > > > > [ Assumes

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

On Thu, 2 Nov 2017 12:46:50 +0100 Petr Mladek wrote: > On Wed 2017-11-01 11:36:47, Steven Rostedt wrote: > > On Wed, 1 Nov 2017 14:38:45 +0100 > > Petr Mladek wrote: > > > My current main worry with Steven's approach is a risk of deadlocks > > > that Jan

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

On Thu, 2 Nov 2017 12:46:50 +0100 Petr Mladek wrote: > On Wed 2017-11-01 11:36:47, Steven Rostedt wrote: > > On Wed, 1 Nov 2017 14:38:45 +0100 > > Petr Mladek wrote: > > > My current main worry with Steven's approach is a risk of deadlocks > > > that Jan Kara saw when he played with similar

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

On Tue 31-10-17 15:32:25, Steven Rostedt wrote: > > Thank you for the perfect timing. You posted this the day after I > proposed a new solution at Kernel Summit in Prague for the printk lock > loop that you experienced here. > > I attached the pdf that I used for that discussion (ignore the last

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

On Tue 31-10-17 15:32:25, Steven Rostedt wrote: > > Thank you for the perfect timing. You posted this the day after I > proposed a new solution at Kernel Summit in Prague for the printk lock > loop that you experienced here. > > I attached the pdf that I used for that discussion (ignore the last

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

On Wed 2017-11-01 11:36:47, Steven Rostedt wrote: > On Wed, 1 Nov 2017 14:38:45 +0100 > Petr Mladek wrote: > > My current main worry with Steven's approach is a risk of deadlocks > > that Jan Kara saw when he played with similar solution. > > And if there exists such a

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

On Wed 2017-11-01 11:36:47, Steven Rostedt wrote: > On Wed, 1 Nov 2017 14:38:45 +0100 > Petr Mladek wrote: > > My current main worry with Steven's approach is a risk of deadlocks > > that Jan Kara saw when he played with similar solution. > > And if there exists such a deadlock, then the

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

On (11/02/17 17:53), Sergey Senozhatsky wrote: > On (10/31/17 15:32), Steven Rostedt wrote: > [..] > > (new globals) > > static DEFINE_SPIN_LOCK(console_owner_lock); > > static struct task_struct console_owner; > > static bool waiter; > > > > console_unlock() { > > > > [ Assumes this part can

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

On (11/02/17 17:53), Sergey Senozhatsky wrote: > On (10/31/17 15:32), Steven Rostedt wrote: > [..] > > (new globals) > > static DEFINE_SPIN_LOCK(console_owner_lock); > > static struct task_struct console_owner; > > static bool waiter; > > > > console_unlock() { > > > > [ Assumes this part can

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

On (10/31/17 15:32), Steven Rostedt wrote: [..] > (new globals) > static DEFINE_SPIN_LOCK(console_owner_lock); > static struct task_struct console_owner; > static bool waiter; > > console_unlock() { > > [ Assumes this part can not preempt ] > > spin_lock(console_owner_lock); >

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

On (10/31/17 15:32), Steven Rostedt wrote: [..] > (new globals) > static DEFINE_SPIN_LOCK(console_owner_lock); > static struct task_struct console_owner; > static bool waiter; > > console_unlock() { > > [ Assumes this part can not preempt ] > > spin_lock(console_owner_lock); >

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

On Wed, 1 Nov 2017 18:42:25 +0100 Vlastimil Babka wrote: > On 11/01/2017 04:33 PM, Steven Rostedt wrote: > > On Wed, 1 Nov 2017 09:30:05 +0100 > > Vlastimil Babka wrote: > > > >> > >> But still, it seems to me that the scheme only works as long as there > >>

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

On Wed, 1 Nov 2017 18:42:25 +0100 Vlastimil Babka wrote: > On 11/01/2017 04:33 PM, Steven Rostedt wrote: > > On Wed, 1 Nov 2017 09:30:05 +0100 > > Vlastimil Babka wrote: > > > >> > >> But still, it seems to me that the scheme only works as long as there > >> are printk()'s coming with some

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

On 11/01/2017 04:33 PM, Steven Rostedt wrote: > On Wed, 1 Nov 2017 09:30:05 +0100 > Vlastimil Babka wrote: > >> >> But still, it seems to me that the scheme only works as long as there >> are printk()'s coming with some reasonable frequency. There's still a >> corner case when a

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

On 11/01/2017 04:33 PM, Steven Rostedt wrote: > On Wed, 1 Nov 2017 09:30:05 +0100 > Vlastimil Babka wrote: > >> >> But still, it seems to me that the scheme only works as long as there >> are printk()'s coming with some reasonable frequency. There's still a >> corner case when a storm of

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

On Wed, 1 Nov 2017 14:38:45 +0100 Petr Mladek wrote: > This was my fear as well. Steven argued that this was theoretical. > And I do not have a real-life bullets against this argument at > the moment. And my argument is still if such a situation happens, the system is so

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

On Wed, 1 Nov 2017 14:38:45 +0100 Petr Mladek wrote: > This was my fear as well. Steven argued that this was theoretical. > And I do not have a real-life bullets against this argument at > the moment. And my argument is still if such a situation happens, the system is so fscked up that it

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

On Wed, 1 Nov 2017 09:30:05 +0100 Vlastimil Babka wrote: > > But still, it seems to me that the scheme only works as long as there > are printk()'s coming with some reasonable frequency. There's still a > corner case when a storm of printk()'s can come that will fill the ring >

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

On Wed, 1 Nov 2017 09:30:05 +0100 Vlastimil Babka wrote: > > But still, it seems to me that the scheme only works as long as there > are printk()'s coming with some reasonable frequency. There's still a > corner case when a storm of printk()'s can come that will fill the ring > buffers, and

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

On Wed 2017-11-01 09:30:05, Vlastimil Babka wrote: > On 10/31/2017 08:32 PM, Steven Rostedt wrote: > > > > Thank you for the perfect timing. You posted this the day after I > > proposed a new solution at Kernel Summit in Prague for the printk lock > > loop that you experienced here. > > > > I

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

On Wed 2017-11-01 09:30:05, Vlastimil Babka wrote: > On 10/31/2017 08:32 PM, Steven Rostedt wrote: > > > > Thank you for the perfect timing. You posted this the day after I > > proposed a new solution at Kernel Summit in Prague for the printk lock > > loop that you experienced here. > > > > I

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

On 10/31/2017 08:32 PM, Steven Rostedt wrote: > > Thank you for the perfect timing. You posted this the day after I > proposed a new solution at Kernel Summit in Prague for the printk lock > loop that you experienced here. > > I attached the pdf that I used for that discussion (ignore the last >

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

On 10/31/2017 08:32 PM, Steven Rostedt wrote: > > Thank you for the perfect timing. You posted this the day after I > proposed a new solution at Kernel Summit in Prague for the printk lock > loop that you experienced here. > > I attached the pdf that I used for that discussion (ignore the last >

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

Thank you for the perfect timing. You posted this the day after I proposed a new solution at Kernel Summit in Prague for the printk lock loop that you experienced here. I attached the pdf that I used for that discussion (ignore the last slide, it was left over and I never went there). My

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

Thank you for the perfect timing. You posted this the day after I proposed a new solution at Kernel Summit in Prague for the printk lock loop that you experienced here. I attached the pdf that I used for that discussion (ignore the last slide, it was left over and I never went there). My

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

On Thu, Oct 26, 2017 at 08:28:59PM +0900, Tetsuo Handa wrote: > [...] it is possible to trigger OOM lockup and/or soft lockups when > many threads concurrently called warn_alloc() (in order to warn > about memory allocation stalls) due to current implementation of > printk(), and it is difficult

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

On Thu, Oct 26, 2017 at 08:28:59PM +0900, Tetsuo Handa wrote: > [...] it is possible to trigger OOM lockup and/or soft lockups when > many threads concurrently called warn_alloc() (in order to warn > about memory allocation stalls) due to current implementation of > printk(), and it is difficult

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

On Thu 26-10-17 20:28:59, Tetsuo Handa wrote: > Commit 63f53dea0c9866e9 ("mm: warn about allocations which stall for too > long") was a great step for reducing possibility of silent hang up problem > caused by memory allocation stalls. But this commit reverts it, for it is > possible to trigger

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

On Thu 26-10-17 20:28:59, Tetsuo Handa wrote: > Commit 63f53dea0c9866e9 ("mm: warn about allocations which stall for too > long") was a great step for reducing possibility of silent hang up problem > caused by memory allocation stalls. But this commit reverts it, for it is > possible to trigger

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

Commit 63f53dea0c9866e9 ("mm: warn about allocations which stall for too long") was a great step for reducing possibility of silent hang up problem caused by memory allocation stalls. But this commit reverts it, for it is possible to trigger OOM lockup and/or soft lockups when many threads

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

Commit 63f53dea0c9866e9 ("mm: warn about allocations which stall for too long") was a great step for reducing possibility of silent hang up problem caused by memory allocation stalls. But this commit reverts it, for it is possible to trigger OOM lockup and/or soft lockups when many threads