Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1540487ybt; Thu, 25 Jun 2020 08:20:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxYG/qfiQUgNIOf2GcHdcniaxXB5uOoLNIKeooOiRSPyRNAZQEunxebtyGEo6vtUsfVB66x X-Received: by 2002:a17:907:72cf:: with SMTP id du15mr29120243ejc.151.1593098457171; Thu, 25 Jun 2020 08:20:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593098457; cv=none; d=google.com; s=arc-20160816; b=RHqXZu7sPSQ8xdmz2AXwY2kj5yoc036aLAjIGFQO1DntEYyfVI3KHjL3lBD5op2MKS 2xqDjwrCStl/Wy1QgJMAx0yN//llp79jGXdnFLd9udQ1W8JrX0ZeIyApzleILt5CnP8O S+uB5WqnHvYhWRz3OkVOpOMG7MWiSOTE7vkwa0Fuz3n50ejb2FUpRXiaNMDBFIJtLeI3 ouMOagBnnimHXLejkm7i7dL7T4wzMGhp3sxMB+kkSV5JXaQQQ2DeTZOwCoKB+h5KRxcn R1+bDOOWzhwDM4LzRCiccQ2KNeK3hdLnSINlqUJWjU9QPYQAgBF6ulCgDT/FibnBr4ev kCWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=JCBJC35GdLag1Z+r3lIqGxchGQ4wzDVxzpyMJV4m+CE=; b=IlXHL7WmhaM+GOrAi//NEDSdL2/r5XFoqqmFPoSqPM+dv95mFiObW4JK/y5QxtzOWX /j43NiqlZ/RUPMReIjIu6Vw80WKimO5cHvsVtUWKdTyZBQWcCi2vt6REuYw8RO5kJYTr Mcr446cW9dW3ckOaMBjWczRr188yJF5Afsra1l1e+SNmOefMR9+s1lElRRwxZacTPRNk CDR8cwWMu5TxG4DrgWoOX1iR/PNGzjz8Q2pNotOYB+quOhkESQfVbzLsW62zL8NwEzxc w3054vmlkAuCz4ALM57/Q4nKZ3Z5F8JR8uhQwQIhwPjICbZtBLMrK+kcQpkV765qFQOh wbpA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d18si8165018ejt.487.2020.06.25.08.20.32; Thu, 25 Jun 2020 08:20:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405689AbgFYPRn (ORCPT + 99 others); Thu, 25 Jun 2020 11:17:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:38988 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405545AbgFYPRn (ORCPT ); Thu, 25 Jun 2020 11:17:43 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 240A1AF49; Thu, 25 Jun 2020 15:17:42 +0000 (UTC) Date: Thu, 25 Jun 2020 17:17:41 +0200 From: Petr Mladek To: John Ogness Cc: Peter Zijlstra , Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Linus Torvalds , Greg Kroah-Hartman , Andrea Parri , Thomas Gleixner , Paul McKenney , kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: pending output optimization: was: [PATCH v3 3/3] printk: use the lockless ringbuffer Message-ID: <20200625151741.GH8444@alley> References: <20200618144919.9806-1-john.ogness@linutronix.de> <20200618144919.9806-4-john.ogness@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200618144919.9806-4-john.ogness@linutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2020-06-18 16:55:19, John Ogness wrote: > Replace the existing ringbuffer usage and implementation with > lockless ringbuffer usage. Even though the new ringbuffer does not > require locking, all existing locking is left in place. Therefore, > this change is purely replacing the underlining ringbuffer. > > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -2009,9 +2056,9 @@ asmlinkage int vprintk_emit(int facility, int level, > > /* This stops the holder of console_sem just where we want him */ > logbuf_lock_irqsave(flags); > - curr_log_seq = log_next_seq; > + pending_output = !prb_read_valid(prb, console_seq, NULL); > printed_len = vprintk_store(facility, level, dict, dictlen, fmt, args); > - pending_output = (curr_log_seq != log_next_seq); > + pending_output &= prb_read_valid(prb, console_seq, NULL); This will stop working after we remove the locks. Consoles will be able to handle messages while the new one is being added. There will be no gurantee that someone is still hadling the previously pending output. Please, always handle consoles when printed_len is not zero!!! The pending output was just an optimization added recently. Nobody requested it. It was just an idea that made sense. This new code is a ticking bomb. It is far from obvious that it _must_ get removed after we remove the lock. And it will be hard to debug why the consoles are sometimes not handled. > logbuf_unlock_irqrestore(flags); > > /* If called from the scheduler, we can not call up(). */ Best Regards, Petr