From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754268AbdLOImm (ORCPT ); Fri, 15 Dec 2017 03:42:42 -0500 Received: from mail-pf0-f195.google.com ([209.85.192.195]:44878 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753549AbdLOIml (ORCPT ); Fri, 15 Dec 2017 03:42:41 -0500 X-Google-Smtp-Source: ACJfBoufdKkpOLuiBWGwCODQRzqcBC3YI4J2C0oMt8/WzqnzyjymaUmMy5lVIZie9UXANdCivmORwA== Date: Fri, 15 Dec 2017 17:42:36 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Tejun Heo , Sergey Senozhatsky , Jan Kara , Andrew Morton , Peter Zijlstra , Rafael Wysocki , Pavel Machek , Tetsuo Handa , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread Message-ID: <20171215084236.GE468@jagdpanzerIV> References: <20171204134825.7822-1-sergey.senozhatsky@gmail.com> <20171214142709.trgl76hbcdwaczzd@pathway.suse.cz> <20171214152551.GY3919388@devbig577.frc2.facebook.com> <20171214125506.52a7e5fa@gandalf.local.home> <20171214181153.GZ3919388@devbig577.frc2.facebook.com> <20171215021024.GA11199@jagdpanzerIV> <20171214221831.3ead0298@vmware.local.home> <20171215050607.GC11199@jagdpanzerIV> <20171215083151.cu3xbdgmxqkszwso@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171215083151.cu3xbdgmxqkszwso@pathway.suse.cz> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (12/15/17 09:31), Petr Mladek wrote: > > On (12/14/17 22:18), Steven Rostedt wrote: > > > > Steven, your approach works ONLY when we have the following preconditions: > > > > > > > > a) there is a CPU that is calling printk() from the 'safe' (non-atomic, > > > > etc) context > > > > > > > > what does guarantee that? what happens if there is NO non-atomic > > > > CPU or that non-atomic simplky missses the console_owner != false > > > > point? we are going to conclude > > > > > > > > "if printk() doesn't work for you, it's because you are holding it wrong"? > > > > > > > > > > > > what if that non-atomic CPU does not call printk(), but instead > > > > it does console_lock()/console_unlock()? why there is no handoff? > > > > > > > > CPU0 CPU1 ~ CPU10 > > > > in atomic contexts [!]. ping-ponging console_sem > > > > ownership to each other. while what they really > > > > need to do is to simply up() and let CPU0 to > > > > handle it. > > > > printk > > > > console_lock() > > > > schedule() > > > > ... > > > > printk > > > > printk > > > > ... > > > > printk > > > > printk > > > > > > > > up() > > > > > > > > // woken up > > > > console_unlock() > > > > > > > > why do we make an emphasis on fixing vprintk_printk()? > > Is the above scenario really dangerous? console_lock() owner is > able to sleep. Therefore there is no risk of a softlockup. > > Sure, many messages will get stacked in the meantime and the console > owner my get then passed to another owner in atomic context. But > do you really see this in the real life? console_sem is locked by atomic printk CPU1~CPU10. non-atomic CPU is just sleeping waiting for the console_sem. while atomic printk CPUs just hand off console_sem ownership to each other without ever up()-ing the console_sem. what's the point of hand off here? how is that going to work? what we need to do is to offload printing from atomic contexts to a non-atomic one - which is CPU0. and that non-atomic CPU is sleeping on the console_sem, ready to continue printing. but it never gets its chance to do so, because CPU0 ~ CPU10 just passing console_sem ownership around, resulting in the same "we print from atomic context" thing. > Of course, there is a chance that it will pass the work from > a safe context to atomic one. But there was the same chance that > the work already started in the atomic context. Therefore statistically > this should not make things worse. which is not a justification. we are not looking for a solution that does not make the things worse. we are looking for a solution that does improve the things. -ss