Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp3415307ybd; Tue, 25 Jun 2019 02:07:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqwFJFv36HPVIZridwjsxXejUQfHHgMu8upwb8o5cCWUR3C0EitHH1v/qZoH67na+Hi0gNrv X-Received: by 2002:a63:c006:: with SMTP id h6mr36915888pgg.285.1561453626929; Tue, 25 Jun 2019 02:07:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561453626; cv=none; d=google.com; s=arc-20160816; b=xvam21TtEIJ7LLVW9XQFQyoXXbzM3n6HS72IjIEpnbMcVOQlXMhE1HgIEmoRrZWWLA x/fgBj0jO6kDrnsNBT5D2jVEyy1XCc2PMRa6tpR7hK2gv1Z5thIVyRChRN4B2YoMs6JE 9AF+3acq4yQ45Y+FUVB4bocOxtqv0+pJ68DdTKCkCSXv+QCyPEfqyUkNNHvrEGMLnO3r 5r+EWDWVUojbKVvbvap1BYpe0bAYtkFz7O67WsmC0fFYe0B2RwQMdHV3P96EkiIf8E1y 8pw7ytjtU1NnIDoCxQPcpwYvdjqJckSBMPm6Uw/6UOYpAHV07sl88/mp4m1FSMR2jp4u Deyw== 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=MtoCFNo4pw4bKZzavrs8XvwHzD5t3mrX3wYQsm4S4Ms=; b=Epp5DMmbUlyW5IDS4zLCaBeVRT3InSVyIC0sDVYX8lZ3YZ6Dut7300nSEyU3BX7zw1 JIBghAKmLgu0S3+hAN9I1jVdZ/lZNdxXBH3uKl762Ht9TMnMgpbA1TPSG792j9HMVW2M iZrmJfgP3EXIpR3EgA62LgJ37ZLv5bjZ+wgmugRrinNGKSQe+PFEt8WfS4lRnpWABwfS Pu7liDF4/dl9CbsO9gckm/fDUftWqZ6Dt3uFFu4AnNJS7z2V3hjtaoIxDH6Sjl8utDos xePxTfa0z50i7SlDbm+uYA83wEkOcsL2DFqXT9M1iMLevxHbdEt3b9gdEKeJI6Rb/5BM 8kRg== 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 d9si13094614pgj.505.2019.06.25.02.06.50; Tue, 25 Jun 2019 02:07:06 -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 S1729825AbfFYJGX (ORCPT + 99 others); Tue, 25 Jun 2019 05:06:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:51634 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728365AbfFYJGX (ORCPT ); Tue, 25 Jun 2019 05:06:23 -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 D323BAEAA; Tue, 25 Jun 2019 09:06:21 +0000 (UTC) Date: Tue, 25 Jun 2019 11:06:20 +0200 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , linux-kernel@vger.kernel.org, Peter Zijlstra , Steven Rostedt , Linus Torvalds , Greg Kroah-Hartman , Andrea Parri , Thomas Gleixner , Sergey Senozhatsky Subject: Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation Message-ID: <20190625090620.wufhvdxxiryumdra@pathway.suse.cz> References: <20190607162349.18199-1-john.ogness@linutronix.de> <20190607162349.18199-2-john.ogness@linutronix.de> <20190618045117.GA7419@jagdpanzerIV> <87imt2bl0k.fsf@linutronix.de> <20190625064543.GA19050@jagdpanzerIV> <20190625071500.GB19050@jagdpanzerIV> <875zoujbq4.fsf@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875zoujbq4.fsf@linutronix.de> 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 Tue 2019-06-25 10:44:19, John Ogness wrote: > On 2019-06-25, Sergey Senozhatsky wrote: > > In vprintk_emit(), are we going to always reserve 1024-byte > > records, since we don't know the size in advance, e.g. > > > > printk("%pS %s\n", regs->ip, current->name) > > prb_reserve(&e, &rb, ????); > > > > or are we going to run vscnprintf() on a NULL buffer first, > > then reserve the exactly required number of bytes and afterwards > > vscnprintf(s) -> prb_commit(&e)? > > (As suggested by Petr) I want to use vscnprintf() on a NULL > buffer. However, a NULL buffer is not sufficient because things like the > loglevel are sometimes added via %s (for example, in /dev/kmsg). So > rather than a NULL buffer, I would use a small buffer on the stack > (large enough to store loglevel/cont information). This way we can use > vscnprintf() to get the exact size _and_ printk_get_level() will see > enough of the formatted string to parse what it needs. vscnprintf() with NULL pointer is perfectly fine. Only the formatted string has variable size. Log level, timestamp, and other information can be stored as metadata with a fixed size, see struct printk_log. They are formatted as text later, see msg_print_text() and msg_print_ext_header(). > > I'm asking this because, well, if the most common usage > > pattern (printk->prb_reserve) will always reserve fixed > > size records (aka data blocks), then you _probably_ (??) > > can drop the 'variable size records' requirement from prb > > design and start looking at records (aka data blocks) as > > fixed sized chunks of bytes, which are always located at > > fixed offsets. > > The average printk message size is well under 128 bytes. It would be > quite wasteful to always reserve 1K blocks. Yes, I think that we need to store the strings in variable sized chunks. Best Regards, Petr