From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 304BCC433EF for ; Wed, 20 Jul 2022 14:08:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240773AbiGTOIC (ORCPT ); Wed, 20 Jul 2022 10:08:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55390 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240756AbiGTOHx (ORCPT ); Wed, 20 Jul 2022 10:07:53 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A854C32464; Wed, 20 Jul 2022 07:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=6PI6oKjncaeSgZdoo1KKImqRT1hx/X10UQeSaaVVn7o=; b=Z3iIfX4rxk/k6ZBDox0GiYaoaN ssjccwkghqIAdo2UAzk9TqFJXYN7hZSqdJERTrGQzGz8OOzqW81Fx4RdGBwbKKohD51w0cJ7frDJF EJU32PQ7ghgtFjx0fhRfZttmk5uAeVTWYIkPbc2dcAjzKL8/VTX8NkE8dpPXLIeA2X1vD5iurZRld 9jbmRtqAyKXgREF3KNag1on2PeaaN8nN2+l/LwuYBBtgEolRCoc71c6eTggKFh33mH1zPrvgzUyXd LfjuZRoJ/dNDsvXzhIZi7vWmBjvuxu8YGYJpoe4QW4JL8le7122J8m+eWN9yL64vCiKlRTH4Y7e5l P/4dUt9w==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=worktop.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEAMT-00EWPO-7A; Wed, 20 Jul 2022 14:07:37 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id D0EED980BBE; Wed, 20 Jul 2022 16:07:36 +0200 (CEST) Date: Wed, 20 Jul 2022 16:07:36 +0200 From: Peter Zijlstra To: Dmitry Dolgov <9erthalion6@gmail.com> Cc: linux-kernel@vger.kernel.org, bpf@vger.kernel.org, songliubraving@fb.com, rostedt@goodmis.org, mingo@redhat.com, mhiramat@kernel.org, alexei.starovoitov@gmail.com Subject: Re: [PATCH v4 1/1] perf/kprobe: maxactive for fd-based kprobe Message-ID: References: <20220714193403.13211-1-9erthalion6@gmail.com> <20220715095236.ywv37a556ktl5oif@ddolgov.remote.csb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220715095236.ywv37a556ktl5oif@ddolgov.remote.csb> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 15, 2022 at 11:52:36AM +0200, Dmitry Dolgov wrote: > > On Thu, Jul 14, 2022 at 09:57:48PM +0200, Peter Zijlstra wrote: > > On Thu, Jul 14, 2022 at 09:34:03PM +0200, Dmitrii Dolgov wrote: > > > From: Song Liu > > > > > > Enable specifying maxactive for fd based kretprobe. This will be useful > > > for tracing tools like bcc and bpftrace (see for example discussion [1]). > > > Use highest 4 bit (bit 59-63) to allow specifying maxactive by log2. > > > > What's maxactive? This doesn't really tell me much. > > Maxactive allows specifying how many instances of the specified function > can be probed simultaneously, it would indeed make sense to mention this > in the commit message. But why would we need per-fd configurability? Isn't a global sysctrl good enough? > > Why are the top 4 bits the best to use? > > This format exists mostly on proposal rights. Per previous discussions, > 4 bits seem to be enough to cover reasonable range of maxactive values. > Top bits seems like a natural place to me following perf_probe_config > enum, but I would love to hear if there are any alternative suggestions? I think the precedent you're referring to is UPROBE_REF_CTR, which is a full 32bit. That lives in the upper half of the word because bit0 is already taken and using the upper half makes the thing naturally aligned. If we only need 4 bits it's must simpler to simply stick it at the bottom or so. > > > > Note that changes in rethook implementation may render maxactive > > > obsolete. > > > > Then why bother creating an ABI for it? > > If I got Masami right, those potential changes mentioned above are only > on the planning stage. At the same time the issue is annoying enough to > try to solve it already now. Masami; how hard would it be to do this? Creating an ABI for something that's already planned to be removed seems unfortunate, it would be best to see if we can find someone to accelerate this work.