Received-SPF: pass (google.com: domain of linux-kernel+bounces-137891-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date: Wed, 10 Apr 2024 06:37:56 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Kyle Huey <me@kylehuey.com>
Cc: Kyle Huey <khuey@kylehuey.com>, linux-kernel@vger.kernel.org,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Marco Elver <elver@google.com>,
	Yonghong Song <yonghong.song@linux.dev>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Robert O'Callahan <robert@ocallahan.org>, bpf@vger.kernel.org
Subject: Re: [RESEND PATCH v5 0/4] Combine perf and bpf for fast eval of hw
 breakpoint conditions]
Message-ID: <ZhYXpNu0c/rcjf0r@gmail.com>
References: <20240214173950.18570-1-khuey@kylehuey.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240214173950.18570-1-khuey@kylehuey.com>


* Kyle Huey <me@kylehuey.com> wrote:

> Peter, Ingo, could you take a look at this?
> 
> ----
> 
> rr, a userspace record and replay debugger[0], replays asynchronous 
> events such as signals and context switches by essentially[1] setting a 
> breakpoint at the address where the asynchronous event was delivered 
> during recording with a condition that the program state matches the 
> state when the event was delivered.
> 
> Currently, rr uses software breakpoints that trap (via ptrace) to the 
> supervisor, and evaluates the condition from the supervisor. If the 
> asynchronous event is delivered in a tight loop (thus requiring the 
> breakpoint condition to be repeatedly evaluated) the overhead can be 
> immense. A patch to rr that uses hardware breakpoints via perf events 
> with an attached BPF program to reject breakpoint hits where the 
> condition is not satisfied reduces rr's replay overhead by 94% on a 
> pathological (but a real customer-provided, not contrived) rr trace.
> 
> The only obstacle to this approach is that while the kernel allows a BPF 
> program to suppress sample output when a perf event overflows it does not 
> suppress signalling the perf event fd or sending the perf event's 
> SIGTRAP. This patch set redesigns __perf_overflow_handler() and 
> bpf_overflow_handler() so that the former invokes the latter directly 
> when appropriate rather than through the generic overflow handler 
> machinery, passes the return code of the BPF program back to 
> __perf_overflow_handler() to allow it to decide whether to execute the 
> regular overflow handler, reorders bpf_overflow_handler() and the side 
> effects of perf event overflow, changes __perf_overflow_handler() to 
> suppress those side effects if the BPF program returns zero, and adds a 
> selftest.

I suppose this optimization makes sense.

Patch quality still needs to be improved though - see my review comments.

Thanks,

	Ingo