Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1017568ybe; Thu, 5 Sep 2019 09:07:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqyoCn9jH+8guXB9rfA6fg5/NZLJYdspA7bmzq76C3zY8lW2D1RTlg9ah/idlkHvuPN+hHzw X-Received: by 2002:a17:902:5c3:: with SMTP id f61mr4022187plf.98.1567699647959; Thu, 05 Sep 2019 09:07:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567699647; cv=none; d=google.com; s=arc-20160816; b=eDmWrzYrL+fosfhWrovQXS3jZp2BYBrxKFMikTTr72D+R/4XIL6MXEGk5ELyWy4H8y WbPiFqxP5HBLEPnnWgZozkalj5ARAQrUlIhnSeNn8gyQ76qQqZavMAt8cnoK7o0cHrSo 4ErELdJFwDI+iMpXSjYeynQFnECSUMV1m0/WHiXR1iEsgh6qCID6YYD6iQ6lOL2hPMmx jXz6apB8Kvp29mNC4/qjqVoFVaQhjXCoocHZ5W3LY+YLFnyRZb3a/lNzEb3f3xlluBT3 lkgL42srWFpQCM5TGdRRkG5xULU31el5Fe/VRCbs876wRstcsEl7gcUVbjMmvvjgGS3W ylFw== 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=EHcPHY0ipnbDkqVhC2RI2rrU+/SNiLfm94bI1uqB/Ck=; b=iATo6Z2faqy3I4jJhxRrTR5cDA08AaTL0FUTgqntDbCfEZGpRswzMResfZS8/yeRMV XmAnZomvvtxmrhabx7IEjpuN9MLL8rugLY+Zy//4+daCtx0Z/RfPfMArt5p6ebvRxf10 xzfjeU4Prncmv2bGvYw4EAi2K4OEAcVJHMhcX4xPrTb9ApAHM/GtJxvCTKUyGPDifSod ERwDu/NWGKe6R5Sr33jLRN3BlgWeAX9ao8yEE0bm+523M6Ln5wJZPuJlgZyjoP/idFRM R+doWW0HzA8+ARtNWPtQfRa0SF9b562I2qe6cywKy4/MJSWzcahwW35TR8iYJl2UNLWi Yuiw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j5si2057529pgm.427.2019.09.05.09.07.09; Thu, 05 Sep 2019 09:07:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388350AbfIENFQ (ORCPT + 99 others); Thu, 5 Sep 2019 09:05:16 -0400 Received: from mx2.suse.de ([195.135.220.15]:50764 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726097AbfIENFQ (ORCPT ); Thu, 5 Sep 2019 09:05:16 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6BD8DAD4B; Thu, 5 Sep 2019 13:05:14 +0000 (UTC) Date: Thu, 5 Sep 2019 15:05:13 +0200 From: Petr Mladek To: Peter Zijlstra Cc: John Ogness , Andrea Parri , Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Brendan Higgins , Thomas Gleixner , Linus Torvalds , Greg Kroah-Hartman , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v4 0/9] printk: new ringbuffer implementation Message-ID: <20190905130513.4fru6yvjx73pjx7p@pathway.suse.cz> References: <20190807222634.1723-1-john.ogness@linutronix.de> <20190904123531.GA2369@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190904123531.GA2369@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2019-09-04 14:35:31, Peter Zijlstra wrote: > On Thu, Aug 08, 2019 at 12:32:25AM +0206, John Ogness wrote: > > Hello, > > > > This is a follow-up RFC on the work to re-implement much of > > the core of printk. The threads for the previous RFC versions > > are here: v1[0], v2[1], v3[2]. > > > > This series only builds upon v3 (i.e. the first part of this > > series is exactly v3). The main purpose of this series is to > > replace the current printk ringbuffer with the new > > ringbuffer. As was discussed[3], this is a conservative > > first step to rework printk. For example, all logbuf_lock > > usage is kept even though the new ringbuffer does not > > require it. This avoids any side-effect bugs in case the > > logbuf_lock is (unintentionally) synchronizing more than > > just the ringbuffer. However, this also means that the > > series does not bring any improvements, just swapping out > > implementations. A future patch will remove the logbuf_lock. > > So after reading most of the first patch (and it look _much_ better than > previous times), I'm left wondering *why* ?! > > That is, why do we need this complexity, as compared to that > CPU serialized approach? The serialized approach used a lock. It was re-entrant and thus less error-prone but still a lock. The lock was planed to be used not only to access the buffer but also for eventual locking inside lockless consoles. It might allow to have some synchronization even in lockless consoles. But it would be big-kernel-lock-like style. It might create yet another maze of problems. If we remove per-CPU buffers in NMI. We would need to synchronize again printing backtraces from all CPUs. Otherwise they would get mixed and hard to read. It might be solved by some prefix and sorting in userspace but... This why I asked to see a fully lockless code to see how more complicated it was. John told me that he had an early version of it around. I agree that this lockless variant is really complicated. I am not able to prove that it is race free as it is now. I understand the algorithm. But there are too many synchronization points. Peter, have you seen my alternative approach, please. See https://lore.kernel.org/lkml/20190704103321.10022-1-pmladek@suse.com/ It uses two tricks: 1. Two bits in the sequence number are used to track the state of the related data. It allows to implement the entire life cycle of each entry using atomic operation on a single variable. 2. There is a helper function to read valid data for each entry, see prb_read_desc(). It checks the state before and after reading the data to make sure that they are valid. And it includes the needed read barriers. As a result there are only three explicit barriers in the code. All other are implicitly done by cmpxchg() atomic operations. The alternative lockless approach is still more complicated than the serialized one. But I think that it is manageable thanks to the simplified state tracking. And I might safe use some pain in the long term. > In my book simpler is better here. printk() is an absolute utter slow > path anyway, nobody cares about the performance much, and I'm thinking > that it should be plenty fast enough as long as you don't run a > synchronous serial output (which is exactly what I do do/require > anyway). I fully agree. Best Regards, Petr