From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id 544EE6B026D for ; Wed, 1 Nov 2017 09:38:50 -0400 (EDT) Received: by mail-pg0-f70.google.com with SMTP id u23so2589991pgo.4 for ; Wed, 01 Nov 2017 06:38:50 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id z187si965397pgb.341.2017.11.01.06.38.48 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 01 Nov 2017 06:38:48 -0700 (PDT) Date: Wed, 1 Nov 2017 14:38:45 +0100 From: Petr Mladek Subject: Re: [PATCH] mm: don't warn about allocations which stall for too long Message-ID: <20171101133845.GF20040@pathway.suse.cz> References: <1509017339-4802-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <20171031153225.218234b4@gandalf.local.home> <187a38c6-f964-ed60-932d-b7e0bee03316@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <187a38c6-f964-ed60-932d-b7e0bee03316@suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: Steven Rostedt , Tetsuo Handa , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Sergey Senozhatsky , "yuwang.yuwang" 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 attached the pdf that I used for that discussion (ignore the last > > slide, it was left over and I never went there). > > > > My proposal is to do something like this with printk: > > > > Three types of printk usages: > > > > 1) Active printer (actively writing to the console). > > 2) Waiter (active printer, first user) > > 3) Sees active printer and a waiter, and just adds to the log buffer > > and leaves. > > > > (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); > > console_owner = current; > > spin_unlock(console_owner_lock); > > > > for each message > > write message out to console > > > > if (READ_ONCE(waiter)) > > break; > > Ah, these two lines clarified for me what I didn't get from your talk, > so I got the wrong impression that the new scheme is just postponing the > problem. > > 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 while during the storm the printing will be distributed > between CPUs nicely, the last unfortunate CPU after the storm subsides > will be left with a large accumulated buffer to print, and there will be > no waiters to take over if there are no more printk()'s coming. What > then, should it detect such situation and defer the flushing? 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. My current main worry with Steven's approach is a risk of deadlocks that Jan Kara saw when he played with similar solution. Also I am afraid that it would add yet another twist to the console locking operations. It is already quite hard to follow the logic, see the games with: + console_locked + console_suspended + can_use_console() + exclusive_console And Steven is going to add: + console_owner + waiter But let's wait for the patch. It might look and work nicely in the end. Best Regards, Petr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org