From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753438AbdLNP0D (ORCPT ); Thu, 14 Dec 2017 10:26:03 -0500 Received: from mail-qt0-f176.google.com ([209.85.216.176]:37931 "EHLO mail-qt0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753223AbdLNP0B (ORCPT ); Thu, 14 Dec 2017 10:26:01 -0500 X-Google-Smtp-Source: ACJfBotelXjvKYaL9Tuc6wJvWMvWjrEQSr9orrBjAL8Me8czpjft4iCmZhNc8xfEtZE7pmeNIx7f7A== Date: Thu, 14 Dec 2017 07:25:51 -0800 From: Tejun Heo To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Jan Kara , Andrew Morton , Peter Zijlstra , Rafael Wysocki , Pavel Machek , Tetsuo Handa , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread Message-ID: <20171214152551.GY3919388@devbig577.frc2.facebook.com> References: <20171204134825.7822-1-sergey.senozhatsky@gmail.com> <20171214142709.trgl76hbcdwaczzd@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171214142709.trgl76hbcdwaczzd@pathway.suse.cz> 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 Hello, Petr. On Thu, Dec 14, 2017 at 03:27:09PM +0100, Petr Mladek wrote: > Ah, I know that it was me who was pessimistic about Steven's approach[1] > and persuaded you that offloading idea was still alive. But I am less > sure now. So, I don't really care which one gets in as long as the livelock problem is fixed although to my obviously partial eyes the two alternatives seem overly complex. That said, > My three main concerns about Steven's approach were: > > 1. I was afraid that it might introduce new type of deadlocks. > > But it seems that it is quite safe after all. > > > 2. Steven's code, implementing the hand shake, is far from trivial. > Few people were confused and reported false bugs. > > But the basic idea is pretty simple and straightforward. If > we manage to encapsulate it into few helpers, it might become > rather self-contained and maintainable. In each case, the needed > changes are much smaller than I expected. > > > 3. Soft-lockups are still theoretically possible with Steven's > approach. > > But it seems to be quite efficient in many real life scenarios, > including Tetsuo's stress testing. Or am I wrong? AFAICS, Steven's approach doesn't fix the livelock that we see quite often in the fleet where we don't have a safe context to keep flushing messages. This isn't theoretical at all. You simply don't have a safe context on the cpu to go to. I said I'd come back with a repro case but haven't had a chance to yet. I'll try to do it before the end of the year, but idk this is pretty obvious. Thanks. -- tejun