From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752049AbdKDEYN (ORCPT <rfc822;w@1wt.eu>);
        Sat, 4 Nov 2017 00:24:13 -0400
Received: from mail-pg0-f68.google.com ([74.125.83.68]:49546 "EHLO
        mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750959AbdKDEYM (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 4 Nov 2017 00:24:12 -0400
X-Google-Smtp-Source: ABhQp+Qi2oGXZGKQGwY+ymRk+RD88GJT/7Bxt9AAkzbos+fcJ9DitYR9VuuMcIY2RAn7mLrb/Ejp/g==
Date: Sat, 4 Nov 2017 13:24:08 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org,
        kernel-team@fb.com, Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/2] Subject: printk: Don't trap random context in
 infinite log_buf flush
Message-ID: <20171104042408.GB539@tigerII.localdomain>
References: <20171102135146.GN3252168@devbig577.frc2.facebook.com>
 <20171102135258.GO3252168@devbig577.frc2.facebook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171102135258.GO3252168@devbig577.frc2.facebook.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On (11/02/17 06:52), Tejun Heo wrote:
> 
> When printk flushing isn't contended, whoever creates messages get to
> flush them, which is great in both fairness and keeping log delivery
> synchronous.  However, when console drivers can't keep up with the
> rate of new messages, which happens a lot, who ends up with the
> flushing duty is determined by timing and everyone else's messages
> become asynchronous.


Hello Tejun,

thanks for the patch set. we are currently looking at another approach:
lkml.kernel.org/r/20171102134515.6eef16de@gandalf.local.home

would you be interested in taking a look?

there are some concerns, like a huge number of printk-s happening while
console_sem is locked. e.g. console_lock()/console_unlock() on one of the
CPUs, or console_lock(); printk(); ... printk(); console_unlock();

>
> the problem of "the last printk()", which will take
> over and do the flush.
> 
> CPU0                                    CPU1  ~  CPU99
> console_lock();
>                                        printk(); ... printk();
> console_unlock();
>                                            IRQ on CPU2
>                                             printk()
>                                              // take over console_sem
>                                              console_unlock()
>

	-ss