From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932463AbdLOPmh (ORCPT ); Fri, 15 Dec 2017 10:42:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:47066 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932168AbdLOPme (ORCPT ); Fri, 15 Dec 2017 10:42:34 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC5C321877 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Fri, 15 Dec 2017 10:42:31 -0500 From: Steven Rostedt To: Petr Mladek Cc: Sergey Senozhatsky , 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: <20171215104231.68267192@gandalf.local.home> In-Reply-To: <20171215083151.cu3xbdgmxqkszwso@pathway.suse.cz> 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> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Dec 2017 09:31:51 +0100 Petr Mladek wrote: > Do people have issues with the current upstream printk() or > still even with Steven's patch? > > My current view is that Steven's patch could not make things > worse. I was afraid of possible deadlock but it seems that I was > wrong. Other than that the patch should make things just better > because it allows to pass the work from time to time a safe way. > > 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. > > This is why I suggest to start with Steven's solution. If people > would still see problems in the real life then we could think > about how to fix it. It is quite likely that we would need to add > offloading to the kthreads in the end but there is a chance... > > In each case, I think that is better to split in into > two or even more steps than introducing one mega-complex > change. And given the many-years resistance against offloading > I tend to start with Steven's approach. THANK YOU!!! This is exactly what I'm trying to convey. > > Does this make some sense, please? It definitely does to me :-) -- Steve