From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752249AbeAJSM6 (ORCPT + 1 other); Wed, 10 Jan 2018 13:12:58 -0500 Received: from mail-qk0-f174.google.com ([209.85.220.174]:38311 "EHLO mail-qk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751831AbeAJSM4 (ORCPT ); Wed, 10 Jan 2018 13:12:56 -0500 X-Google-Smtp-Source: ACJfBotuQg1wwCTW/Fe2lpCeEm73DqorCvGw98055VWd4Ivz5t4Q0FmLBSHy4z8MgIaSLW7ry9BLSA== Date: Wed, 10 Jan 2018 10:12:52 -0800 From: Tejun Heo To: Steven Rostedt Cc: 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: <20180110181252.GK3668920@devbig577.frc2.facebook.com> References: <20180110132418.7080-1-pmladek@suse.com> <20180110140547.GZ3668920@devbig577.frc2.facebook.com> <20180110130517.6ff91716@vmware.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180110130517.6ff91716@vmware.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hello, Steven. So, everything else on your message, sure. You do what you have to do, but I really don't understand the following part, and this has been the main source of frustration in the whole discussion. On Wed, Jan 10, 2018 at 01:05:17PM -0500, Steven Rostedt wrote: > You on the other hand are showing unrealistic scenarios, and crying > that it's what you see in production, with no proof of it. I've explained the same scenario multiple times. Unless you're assuming that I'm lying, it should be amply clear that the scenario is unrealistic - we've been seeing them taking place repeatedly for quite a while. What I don't understand is why we can't address this seemingly obvious problem. If there are technical reasons and the consensus is to not solve this within flushing logic, sure, we can deal with it otherwise, but we at least have to be able to agree that there are actual issues here, no? Thanks. -- tejun