Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753629AbeAKFfO (ORCPT + 1 other); Thu, 11 Jan 2018 00:35:14 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:39793 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750799AbeAKFfM (ORCPT ); Thu, 11 Jan 2018 00:35:12 -0500 X-Google-Smtp-Source: ACJfBouRqfZUeqFA2FruNveIGP3+dtJ4ohTEu95ZKNUyxcW0YmPi3B9vBr7Blzv7aFBhf5uJy1BXlQ== Date: Thu, 11 Jan 2018 14:35:07 +0900 From: Sergey Senozhatsky To: Steven Rostedt Cc: Tejun Heo , Petr Mladek , Sergey Senozhatsky , 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 , Sergey Senozhatsky , Pavel Machek , linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180111053507.GD494@jagdpanzerIV> References: <20180110132418.7080-1-pmladek@suse.com> <20180110140547.GZ3668920@devbig577.frc2.facebook.com> <20180110130517.6ff91716@vmware.local.home> <20180110181252.GK3668920@devbig577.frc2.facebook.com> <20180110134157.1c3ce4b9@vmware.local.home> <20180110185747.GO3668920@devbig577.frc2.facebook.com> <20180110141758.1f88e1a0@vmware.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180110141758.1f88e1a0@vmware.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 Return-Path: On (01/10/18 14:17), Steven Rostedt wrote: [..] > OK, lets start over. good. > Right now my focus is an incremental approach. I'm not trying to solve > all issues that printk has. I've focused on a single issue, and that is > that printk is unbounded. Coming from a Real Time background, I find > that is a big problem. I hate unbounded algorithms. agreed! so why not bound it to watchdog threshold then? why bound it to a random O(logbuf) thing? which is not even constant. when you un-register or disable one or several consoles then call_console_drivers() becomes faster; when you register/enable consoles then the entire call_console_drivers() becomes slower. how do we build a reliable algorithm on that O(logbuf)? -ss