Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751972AbeAPTpC (ORCPT + 1 other); Tue, 16 Jan 2018 14:45:02 -0500 Received: from mail-qk0-f177.google.com ([209.85.220.177]:44466 "EHLO mail-qk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751796AbeAPTpA (ORCPT ); Tue, 16 Jan 2018 14:45:00 -0500 X-Google-Smtp-Source: ACJfBosPAOYaAKmnVuxcZjeKGM4tiWqXe7JBy8J2Enq1Ll8NxEhkYOoyELK698lgoBYvw80nacpbWw== Date: Tue, 16 Jan 2018 11:44:56 -0800 From: Tejun Heo To: Steven Rostedt Cc: Sergey Senozhatsky , 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 , Pavel Machek , linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180116194456.GS3460072@devbig577.frc2.facebook.com> References: <20180110132418.7080-1-pmladek@suse.com> <20180110140547.GZ3668920@devbig577.frc2.facebook.com> <20180110130517.6ff91716@vmware.local.home> <20180111045817.GA494@jagdpanzerIV> <20180111093435.GA24497@linux.suse> <20180111103845.GB477@jagdpanzerIV> <20180111112908.50de440a@vmware.local.home> <20180111203057.5b1a8f8f@gandalf.local.home> <20180111215547.2f66a23a@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180111215547.2f66a23a@gandalf.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. On Thu, Jan 11, 2018 at 09:55:47PM -0500, Steven Rostedt wrote: > All I did was start off a work queue on each CPU, and each CPU does one > printk() followed by a millisecond sleep. No 10,000 printks, nothing > in an interrupt handler. Preemption is disabled while the printk > happens, but that's normal. > > This is much closer to an OOM happening all over the system, where OOMs > stack dumps are occurring on different CPUS. OOMs can't happen all over the system. It can only happen on a single CPU at a time. If you're printing from multiple CPUs, your solution would work great. That is the situation your patches are designed to address to begin with. That isn't the problem that I reported tho. I understand that your solution works for that class of problems and that is great. I really wish that it could address the other class of problems too tho, and it doesn't seem like it would be that difficult to cover both cases, right? Thanks. -- tejun