From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752250AbeAQG32 (ORCPT + 1 other); Wed, 17 Jan 2018 01:29:28 -0500 Received: from mail-pg0-f54.google.com ([74.125.83.54]:45125 "EHLO mail-pg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750853AbeAQG30 (ORCPT ); Wed, 17 Jan 2018 01:29:26 -0500 X-Google-Smtp-Source: ACJfBosG8A6MFFoDoguVLtEYtCY8+OxEpOCa5JUGfDoa0akRWF3irto9zr6gaL9zo+Sh87LwWEfwmQ== Date: Wed, 17 Jan 2018 15:29:20 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Sergey Senozhatsky , Tejun Heo , akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Linus Torvalds , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , rostedt@home.goodmis.org, Byungchul Park , Pavel Machek , linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180117062920.GD423@jagdpanzerIV> References: <20180111112908.50de440a@vmware.local.home> <20180112025612.GB6419@jagdpanzerIV> <20180111222140.7fd89d52@gandalf.local.home> <20180112100544.GA441@jagdpanzerIV> <20180112072123.33bb567d@gandalf.local.home> <20180113072834.GA1701@tigerII.localdomain> <20180115070637.1915ac20@gandalf.local.home> <20180115144530.pej3k3xmkybjr6zb@pathway.suse.cz> <20180116022349.GD6607@jagdpanzerIV> <20180116101355.iy7q3pqxzzlpdiht@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180116101355.iy7q3pqxzzlpdiht@pathway.suse.cz> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On (01/16/18 11:13), Petr Mladek wrote: [..] > IMHO, it would make sense if flushing the printk buffer behaves > the same when called either from printk() or from any other path. > I mean that it should be aggressive and allow an effective > hand off. > > It should be safe as long as foo_specific_work() does not take > too much time. > > From other side. The cond_resched() in console_unlock() should > be obsoleted by the hand-shake code. hm, let's not have too optimistic expectations. hand off works in very specific conditions. console is not exclusively owned by printk, and console_sem is not printk's own lock. even things like systemd -> n_tty_write -> do_output_char -> con_write involves console_lock() and console_unlock(). IOW user space logging/debugging can cause printk stalls, and vice versa. by the way, do_con_write() explicitly calls console_conditional_schedule() under console_sem, before it goes to console_unlock(). so the scope of "situation normal, console_sem locked, the owner scheduled out" is much bigger than just vprintk_emit() -> console_unlock(). IMHO. and there are even more things there. personally, I don't think that hand off is enough to obsolete anything in that area. [...] > They both were obvious solutions that helped to reduce the risk > of soft-lockups. The first one handled evidently safe scenarios. > The second one was even more aggressive. I would say that > they both were more or less add-hoc solutions that did not > take into account the other side effects (delaying output, > even loosing messages). agreed. > I would not say that one is a diametric difference between them. > Therefore if we remove one for a reason, we should think about > reverting the other as well. But again. I am fine if we remove > only one now. > > Does this make any sense? I see cond_resched() as a mirroring of console_lock()->console_unlock() behaviour on PREEMPT systems, and as such it looks valid to me, so we probably better keep it there. IMHO. -ss