From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BCAC7318E for ; Thu, 21 Dec 2023 13:00:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046060;MF=lulie@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0Vyxmfz9_1703163640; Received: from 30.221.128.103(mailfrom:lulie@linux.alibaba.com fp:SMTPD_---0Vyxmfz9_1703163640) by smtp.aliyun-inc.com; Thu, 21 Dec 2023 21:00:41 +0800 Message-ID: Date: Thu, 21 Dec 2023 21:00:39 +0800 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Question about bpf perfbuf/ringbuf: pinned in backend with overwriting To: Steven Rostedt Cc: Andrii Nakryiko , Shung-Hsi Yu , bpf@vger.kernel.org, song@kernel.org, andrii@kernel.org, ast@kernel.org, Daniel Borkmann , xuanzhuo@linux.alibaba.com, dust.li@linux.alibaba.com, guwen@linux.alibaba.com, alibuda@linux.alibaba.com, hengqi@linux.alibaba.com, Nathan Slingerland , "rihams@meta.com" , Alan Maguire , Masami Hiramatsu References: <3dd9114c-599f-46b2-84b9-abcfd2dcbe33@linux.alibaba.com> <23691bb5-9688-4e93-a98c-1024e8a8fc62@linux.alibaba.com> <20231219083851.0ec83349@gandalf.local.home> From: Philo Lu In-Reply-To: <20231219083851.0ec83349@gandalf.local.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Steven, Thanks for your explanation about ftrace ring buffer. Also thanks to Shung-Hsi for the discussion. Here are some features of ftrace buffer that I'm not sure if they are right. Could you please tell me if my understandings correct? (1) When reading and writing occur concurrently: (a) If reader is faster than writer, the reader cannot get the page which is still being written, which means the reader cannot get the data immediately of one-page length in the worst case. (b) If writer is faster than reader, the only race between them is when reader is doing swap while writer wraps in overwrite mode. But if the reader has finished swapping, the writer can wrap safely, because the reader page if already out of the buffer page list. (2) As the per-cpu buffer list is dynamic with reader page moves, we cannot do mmap to expose the buffer to user. Users can consume at most one page at a time. (3) The wake-up behavior is controllable. If there is no waiter at all, no overhead will be induced because of waking up. Thanks. On 2023/12/19 21:38, Steven Rostedt wrote: > On Tue, 19 Dec 2023 14:23:59 +0800 > Shung-Hsi Yu wrote: > >> Curious whether it is possible to reuse ftrace's trace buffer instead >> (or it's underlying ring buffer implementation at >> kernel/trace/ring_buffer.c). AFAICT it satisfies both requirements that >> Philo stated: (1) no need for user process as the buffer is accessible >> through tracefs, and (2) has an overwrite mode. > > Yes, the ftrace ring-buffer was in fact designed for the above use case. > >> >> Further more, a natural feature request that would come after >> overwriting support would be snapshotting, and that has already been >> covered in ftrace. > > Yes, it has that too. > >> >> Note: technically BPF program could already write to ftrace's trace >> buffer with the bpf_trace_vprintk() helper, but that goes through string >> formatting and only allows writing into to the global buffer. > > When eBPF was first being developed, Alexei told me he tried the ftrace > ring buffer, and he said the filtering was too slow. That's because it > would always write into the ring buffer and then try to discard it after > the fact, which required a few cmpxchg to synchronize. He decided that the > perf ring buffer was a better fit for this. > > That was solved with this: 0fc1b09ff1ff4 ("tracing: Use temp buffer when > filtering events") Which makes the filtering similar to perf as perf always > copies events to a temporary buffer first. > > It still falls back to writing directly into the ring buffer if the temp > buffer is currently being used by another event on the same CPU. > > Note that the perf ring buffer was designed for profiling (taking > intermediate traces) and tightly coupled to have a reader. Whereas the > ftrace ring buffer was designed for high speed constant tracing, with or > without a reader. > > -- Steve