From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754160AbdLTHrC (ORCPT ); Wed, 20 Dec 2017 02:47:02 -0500 Received: from mail-pg0-f45.google.com ([74.125.83.45]:40554 "EHLO mail-pg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751384AbdLTHrB (ORCPT ); Wed, 20 Dec 2017 02:47:01 -0500 X-Google-Smtp-Source: ACJfBouWMp1aM3xF5pVy9qQ5QIJnpf4ODrRoMBbmZE4Loo1nu2kYpAEccrF9/QLxfMpT78GNXHusQg== Date: Wed, 20 Dec 2017 16:46:54 +0900 From: Sergey Senozhatsky To: Steven Rostedt Cc: Sergey Senozhatsky , Petr Mladek , 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: <20171220074654.GB11774@jagdpanzerIV> References: <20171218141353.6shpvcwth34k6dsi@pathway.suse.cz> <20171218124613.1df152da@gandalf.local.home> <20171219010311.GB8892@jagdpanzerIV> <20171218200806.56a6507e@gandalf.local.home> <20171219012455.GB17164@jagdpanzerIV> <20171218210356.71a1f60e@vmware.local.home> <20171219024610.GC17164@jagdpanzerIV> <20171218223817.0e7f866e@vmware.local.home> <20171219045846.GE17164@jagdpanzerIV> <20171219094052.15a94379@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171219094052.15a94379@gandalf.local.home> 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/19/17 09:40), Steven Rostedt wrote: > On Tue, 19 Dec 2017 13:58:46 +0900 > Sergey Senozhatsky wrote: > > > so you are not convinced that my scenarios real/matter; I'm not > > Well, not with the test module. I'm looking for actual code in the > upstream kernel. > > > convinced that I have stable and functional boards with this patch ;) > > seems that we are coming to a dead end. > > Can I ask, is it any worse than what we have today? that's a really hard question. both the existing printk() and the tweaked printk() have the same thing in common - a) preemption from console_unlock() and b) printk() being way to fast compared to anything else (call_console_drivers() and to preemption latency of console_sem owner). your patch puts some requirements that my workload simply cannot fulfill. so may be if I'll start pushing it towards OOM and so on, then I'll see some difference (but both (a) and (b) still gonna stay true). the thing that really changes everything is offloading to printk_kthread. given that I can't have a tiny logbuf, and that I can't have fast console, and that I can't have tons of printks to chose from and to get advantage of hand off algorithm in any reliable way; I need something more to guarantee that the current console_sem will not be forced to evict all logbuf messages. > > for the record, > > I'm not going to block the patch if you want it to be merged. > > Thanks, I mean it :) -ss