Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp697179rwe; Wed, 31 Aug 2022 09:24:58 -0700 (PDT) X-Google-Smtp-Source: AA6agR6jQd7DY1vj5aU9u4+6uJAYC3VPC75D5aBWkD/QoQWjxseKJ5fv1PMsQ6thj3Rn+sNmAYqD X-Received: by 2002:a17:907:75c6:b0:741:75a0:b82b with SMTP id jl6-20020a17090775c600b0074175a0b82bmr12266100ejc.465.1661963098027; Wed, 31 Aug 2022 09:24:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661963098; cv=none; d=google.com; s=arc-20160816; b=MPG8UU+Ug4scDrMkv/jUXG40HnCnQvnixF3vaBAWIuwMo0pYIEvOR0gNBF2LiJURCB A18b+ayZStEy969FymquS3rqOSA82o7Wb9/fBHW9BmMGL+y8+yHyW7Xy33udlNNE6r4l DbNotNrhAjStUXood1wDHeGk4A0WsiLsIAuU+VOS0NhUGjb7l/zMuk9ZU9TuGazkldHB GLV5Ev/c25zW7DHfyPqXTSYhr7ES+LEKbttlJJ3VWvcZmsexP2P8sCKMLJOU+AAWE18o 7caqhGoJ0ftXsyVfgmWCeN9nG6vdWhtkkgVlwhNwkdCPCvnD3CnP5/7yGpPZ+oDcftkG Gtjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:dkim-signature:date; bh=8eQR8jMOxB0pUJLRgI0y5+reUXpRdgSKiz76DZMbpZA=; b=zsTJPju5SgwgC0zDQ44yhRcqQReLcdiAF1kI05fnRU+hR/h5rHDKAa421hHP+se2Uz 5E0hVe+zynyeX85x7Zj8YkgeJ0j46rGf6tHpwZIf0dNQyO7n6quL1X9g/422zVr4oBIx FJ7J2O0yhHPPhD4IPt6N1ny3YU9Sgk/pD2OOpbnqn3+PKe0QWhs0phVQ2NS6IerRfpoh 58CWUSgGelVms4xpxxac7UJDB5hs/PvFRf4WS7T+8EM7X88pWkXBW2XD4kRpkbf7bTzA ZdnsCrsKwa38GeZalxrxdUDvMD8QowRe/XwTiBnE62CYsf/dZJoqqpPmvv3Dmm5H78e/ iujw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=GKQv6dES; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hb20-20020a170907161400b0073da6628a3esi11950601ejc.682.2022.08.31.09.24.31; Wed, 31 Aug 2022 09:24:58 -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; dkim=pass header.i=@linux.dev header.s=key1 header.b=GKQv6dES; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229689AbiHaP76 (ORCPT + 99 others); Wed, 31 Aug 2022 11:59:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229476AbiHaP7y (ORCPT ); Wed, 31 Aug 2022 11:59:54 -0400 Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01A7625EB; Wed, 31 Aug 2022 08:59:50 -0700 (PDT) Date: Wed, 31 Aug 2022 11:59:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1661961589; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8eQR8jMOxB0pUJLRgI0y5+reUXpRdgSKiz76DZMbpZA=; b=GKQv6dESmRNVlYrhLKqHqAEupQL+NGWnc+q+XSzgFWGRhe0CnbyNV+7rNtWq5MTMG51R4C l0UYS35OVMaetPyb4bctosq1HXD3sGEB3YcTrl1fFrr7arsrOVKztpQ7iNKwwum1q08tZq 71z4eskGeNO/LfuPYzvdz8RnP/XW/uU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Mel Gorman Cc: Peter Zijlstra , Suren Baghdasaryan , akpm@linux-foundation.org, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, void@manifault.com, juri.lelli@redhat.com, ldufour@linux.ibm.com, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, changbin.du@intel.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, arnd@arndb.de, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-mm@kvack.org, iommu@lists.linux.dev, kasan-dev@googlegroups.com, io-uring@vger.kernel.org, linux-arch@vger.kernel.org, xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 00/30] Code tagging framework and applications Message-ID: <20220831155941.q5umplytbx6offku@moria.home.lan> References: <20220830214919.53220-1-surenb@google.com> <20220831084230.3ti3vitrzhzsu3fs@moria.home.lan> <20220831101948.f3etturccmp5ovkl@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220831101948.f3etturccmp5ovkl@suse.de> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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, Aug 31, 2022 at 11:19:48AM +0100, Mel Gorman wrote: > On Wed, Aug 31, 2022 at 04:42:30AM -0400, Kent Overstreet wrote: > > On Wed, Aug 31, 2022 at 09:38:27AM +0200, Peter Zijlstra wrote: > > > On Tue, Aug 30, 2022 at 02:48:49PM -0700, Suren Baghdasaryan wrote: > > > > =========================== > > > > Code tagging framework > > > > =========================== > > > > Code tag is a structure identifying a specific location in the source code > > > > which is generated at compile time and can be embedded in an application- > > > > specific structure. Several applications of code tagging are included in > > > > this RFC, such as memory allocation tracking, dynamic fault injection, > > > > latency tracking and improved error code reporting. > > > > Basically, it takes the old trick of "define a special elf section for > > > > objects of a given type so that we can iterate over them at runtime" and > > > > creates a proper library for it. > > > > > > I might be super dense this morning, but what!? I've skimmed through the > > > set and I don't think I get it. > > > > > > What does this provide that ftrace/kprobes don't already allow? > > > > You're kidding, right? > > It's a valid question. From the description, it main addition that would > be hard to do with ftrace or probes is catching where an error code is > returned. A secondary addition would be catching all historical state and > not just state since the tracing started. Catching all historical state is pretty important in the case of memory allocation accounting, don't you think? Also, ftrace can drop events. Not really ideal if under system load your memory accounting numbers start to drift. > It's also unclear *who* would enable this. It looks like it would mostly > have value during the development stage of an embedded platform to track > kernel memory usage on a per-application basis in an environment where it > may be difficult to setup tracing and tracking. Would it ever be enabled > in production? Would a distribution ever enable this? If it's enabled, any > overhead cannot be disabled/enabled at run or boot time so anyone enabling > this would carry the cost without never necessarily consuming the data. The whole point of this is to be cheap enough to enable in production - especially the latency tracing infrastructure. There's a lot of value to always-on system visibility infrastructure, so that when a live machine starts to do something wonky the data is already there. What we've built here this is _far_ cheaper than anything that could be done with ftrace. > It might be an ease-of-use thing. Gathering the information from traces > is tricky and would need combining multiple different elements and that > is development effort but not impossible. > > Whatever asking for an explanation as to why equivalent functionality > cannot not be created from ftrace/kprobe/eBPF/whatever is reasonable. I think perhaps some of the expectation should be on the "ftrace for everything!" people to explain a: how their alternative could be even built and b: how it would compare in terms of performance and ease of use. Look, I've been a tracing user for many years, and it has its uses, but some of the claims I've been hearing from tracing/bpf people when any alternative tooling is proposed sound like vaporware and bullshitting.