From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966176AbdLSBKF (ORCPT ); Mon, 18 Dec 2017 20:10:05 -0500 Received: from mail-pf0-f195.google.com ([209.85.192.195]:36861 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935898AbdLSBKE (ORCPT ); Mon, 18 Dec 2017 20:10:04 -0500 X-Google-Smtp-Source: ACJfBounllfqS68dIbteAa7rX2PB8Fg34Avp6Gq5qb4WCB8bno3DH063S2Jx6y/3ziVB6RiYGodu6A== Date: Tue, 19 Dec 2017 10:09:59 +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: <20171219010959.GA17164@jagdpanzerIV> References: <20171214181153.GZ3919388@devbig577.frc2.facebook.com> <20171215021024.GA11199@jagdpanzerIV> <20171214221831.3ead0298@vmware.local.home> <20171215050607.GC11199@jagdpanzerIV> <20171215083151.cu3xbdgmxqkszwso@pathway.suse.cz> <20171215084236.GE468@jagdpanzerIV> <20171215090801.eulx4pg54p667ya5@pathway.suse.cz> <20171218093405.GA31274@jagdpanzerIV> <20171218133101.ri55uwivhc5xwg5y@pathway.suse.cz> <20171218141037.m6o6bicx5xhpjbl6@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171218141037.m6o6bicx5xhpjbl6@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 On (12/18/17 15:10), Petr Mladek wrote: [..] > > All this is in the current upstream code as well. Steven's patch > > should make it better in compare with the current upstream code. > > > > Sure, the printk offload approach does all these things better. > > But there is still the fear that the offload is not reliable > > in all situations. The lazy offload should handle this well from > > my POV but I am not 100% sure. > > BTW: There is one interesting thing. If we rely on the kthread > to handle flood of messages. It might be too slow because it > reschedules. It might cause loosing messages. Note that > the kthread should have rather normal priority to avoid > blocking other processes. ... and this is why preemption is disabled in console_unlock() in the patch set I have posted. obviously you haven't even looked at the patches. wonderful. -ss