From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754266AbdKANiu (ORCPT ); Wed, 1 Nov 2017 09:38:50 -0400 Received: from mx2.suse.de ([195.135.220.15]:57181 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751738AbdKANis (ORCPT ); Wed, 1 Nov 2017 09:38:48 -0400 Date: Wed, 1 Nov 2017 14:38:45 +0100 From: Petr Mladek 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" 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> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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