Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp43060rwl; Tue, 28 Mar 2023 20:30:47 -0700 (PDT) X-Google-Smtp-Source: AK7set9h9+8AoFEggGZZ/N7w5xhn59RRenK1aaCMZdNjZMgOzfGbwcnp1yePcVddHRViypz5ODdN X-Received: by 2002:a05:6a20:7a90:b0:d9:bf06:cd85 with SMTP id u16-20020a056a207a9000b000d9bf06cd85mr15886671pzh.25.1680060647220; Tue, 28 Mar 2023 20:30:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680060647; cv=none; d=google.com; s=arc-20160816; b=DvxHum6va3j4XrJglvc4TuIEXx+/Tc0xZiKDDj7zwKhMJPZphv+4i32pb12+LGEG4R iLBfHQak+WlzkQ9HLQ6Inev84TTp4vverN+H+7tnlkUA2t9LQreVgPVBG1+jJa+VvItX UWSDRIHnmYlaDmQm6Z7Jv//WEK5Q36tsXaUkEMyWQ8V2etwjkJ4o92yrNniuL2xCL1GC GEgp8DIcSJa98jJ5oTeIpcp8WM7mcaKnfkM6s1ABZikRfKRs1bQBqDBk1Trqc+xUqLzf VVtTMWkx787IwB2Mhb1bc14MBVzi2PyIAa0Dbk2I5L3NzzIvppnhBoEbzvgCPsBQxmvx JQEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=dVwZFS7XSNjhFIPLyR9185q5/wf0wTxlhTvYBFdFoB4=; b=YHqba0PazzRV1XaStl1d8Hz0S+QXzpRpmE0TZFMyPT2phxAvxnKCyCRaebV1/6JjbB kwsxHHAQvswGact24TgICxLjiCIAejSX+CMw9dWnysDUIvWqpf8VMLIL+FCKZGY0+hG+ 6aWTdtTpx+2ZRNZGehFBS+WYOt3qlCTTS7zHDTifr6O0Nd63LwMAgg4xeh+MeN208tx1 hoP6wuu3RwC93XiViGW7dj60MYeoMWuBaj7utBPGI1yONme5Xu+JNsBnsWIOEWyItcXM NCmsqumrGa/YV7HRcMff3170iRoQAzxVcfd7Xr62Mf8Zy9wvCdm6F86b9Ip98q0z//x6 66AQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q4-20020a056a0002a400b005f681d0192csi13429911pfs.27.2023.03.28.20.30.30; Tue, 28 Mar 2023 20:30:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229793AbjC2CoS (ORCPT + 99 others); Tue, 28 Mar 2023 22:44:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229524AbjC2CoR (ORCPT ); Tue, 28 Mar 2023 22:44:17 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 696AA2139; Tue, 28 Mar 2023 19:44:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 18842B81EA9; Wed, 29 Mar 2023 02:44:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34F9EC433EF; Wed, 29 Mar 2023 02:44:13 +0000 (UTC) Date: Tue, 28 Mar 2023 22:44:11 -0400 From: Steven Rostedt To: Vincent Donnefort Cc: mhiramat@kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v2 1/2] ring-buffer: Introducing ring-buffer mapping functions Message-ID: <20230328224411.0d69e272@gandalf.local.home> In-Reply-To: <20230322102244.3239740-2-vdonnefort@google.com> References: <20230322102244.3239740-1-vdonnefort@google.com> <20230322102244.3239740-2-vdonnefort@google.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 22 Mar 2023 10:22:43 +0000 Vincent Donnefort wrote: > +#include > + > +struct ring_buffer_meta_page_header { > +#if __BITS_PER_LONG == 64 > + __u64 entries; > + __u64 overrun; > +#else > + __u32 entries; > + __u32 overrun; > +#endif > + __u32 pages_touched; > + __u32 meta_page_size; > + __u32 reader_page; /* page ID for the reader page */ > + __u32 nr_data_pages; /* doesn't take into account the reader_page */ > + __u32 data_page_head; /* ring-buffer head as an offset from data_start */ > + __u32 data_start; /* offset within the meta page */ > +}; > + I've been playing with this a bit, and I'm thinking, do we need the data_pages[] array on the meta page? I noticed that I'm not even using it. Currently, we need to do a ioctl every time we finish with the reader page, and that updates the reader_page in the meta data to point to the next page to read. When do we need to look at the data_start section? -- Steve