Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp894592rwe; Wed, 31 Aug 2022 13:03:07 -0700 (PDT) X-Google-Smtp-Source: AA6agR5BsWG1dILNwYVVTz4+Vg8LJSrR4TkqeF6HKqVUQcLv0iw4O/CGwlZ2FsALO5kbsrdQTOEm X-Received: by 2002:a17:907:272a:b0:741:8105:49e2 with SMTP id d10-20020a170907272a00b00741810549e2mr11682846ejl.171.1661976187437; Wed, 31 Aug 2022 13:03:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661976187; cv=none; d=google.com; s=arc-20160816; b=thhTXsdUfPWuKl5cWEg+0k/gspWgpsMEyLSbCRmlkl0FiLMZNIXgifCeIX5fjKwAtr PGeuMS47ItPEcQvsa7Ij6PnFqZDMSj5sYYVPOu86CLeZ+ReI7k/0oMXxYrorLDvNa/SI Vn3eTLkYwkoiU3LypLawbZWhufSNkDVESUWHUW/ZlqLQSpAh4biG5QSKycgQVgmpQqr+ Y4qAOvBHVYDgd5DgleMu3v40i8z9zHPNs8wIdf+AVFLyjkyCCHHL6CsU5eCAylVvXTkV EP43QSNadddI0G0UHZfrcmlzaR5QPXBo3PzZIElHKRJ2YO1Sf3GurIYVxXizVIUJKk17 M8xg== 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=/S1Z12zwQROoKfTz1twMnESk8KqrSv9O32o/CoebBns=; b=B4KguNTb5l/IPL4iaJlLkz5C1/M4zvQ2xVQsrZ84Z2/VSx7L8pF0eWJxPJBTgSGMWL FMokdIdEdVc1Kx0DEKBdj0q5bANEg7x+l/jrah5tu67Xm3t5tcqq/o9QJp3ji/7g0l+S OZewdVMLUUKn3uOawoRrokgo3zSmq/26RqTNjBcc0C6d3YlLDyWEhq1rGHdU4TlcqHmF w2NalyQq/lkIWQltCgQuk5MLsCTUCSdH1vASZw6C5SXHuFNB3UwibdhbqTmMcOLztQYe /gSSTJaikXMmwoylEX2yEiUW7YscLy8Mnjl3+Y53052w+sdM07jS/Q6KzBLSY+qOIteC BKug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b="sF/L6oga"; 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 l2-20020a1709067d4200b0073d719f1447si10348309ejp.426.2022.08.31.13.02.40; Wed, 31 Aug 2022 13:03:07 -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="sF/L6oga"; 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 S231588AbiHaTCd (ORCPT + 99 others); Wed, 31 Aug 2022 15:02:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232536AbiHaTCN (ORCPT ); Wed, 31 Aug 2022 15:02:13 -0400 Received: from out2.migadu.com (out2.migadu.com [IPv6:2001:41d0:2:aacc::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95EF4CB5E0; Wed, 31 Aug 2022 12:02:05 -0700 (PDT) Date: Wed, 31 Aug 2022 15:01:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1661972523; 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=/S1Z12zwQROoKfTz1twMnESk8KqrSv9O32o/CoebBns=; b=sF/L6ogajTfppllZKwsY3yAp/F+VbzSHnCHZx0MwHJq3wLBzznsc7Lb2ZsCP4rEQgcNT28 rLvWmn6gmqWCcSF6VIihZIZ70OK4+CXbASmvLSrwtHuf1uHUi1DngGVeWjfIGxIWF0Ihh2 Si0kCu7ZLzOp8dHrcYN8kmqyIqxg/Wk= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Mel Gorman , Peter Zijlstra , Suren Baghdasaryan , akpm@linux-foundation.org, 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: <20220831190154.qdlsxfamans3ya5j@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: 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 12:47:32PM +0200, Michal Hocko wrote: > On Wed 31-08-22 11:19:48, Mel Gorman wrote: > > Whatever asking for an explanation as to why equivalent functionality > > cannot not be created from ftrace/kprobe/eBPF/whatever is reasonable. > > Fully agreed and this is especially true for a change this size > 77 files changed, 3406 insertions(+), 703 deletions(-) In the case of memory allocation accounting, you flat cannot do this with ftrace - you could maybe do a janky version that isn't fully accurate, much slower, more complicated for the developer to understand and debug and more complicated for the end user. But please, I invite anyone who's actually been doing this with ftrace to demonstrate otherwise. Ftrace just isn't the right tool for the job here - we're talking about adding per callsite accounting to some of the fastest fast paths in the kernel. And the size of the changes for memory allocation accounting are much more reasonable: 33 files changed, 623 insertions(+), 99 deletions(-) The code tagging library should exist anyways, it's been open coded half a dozen times in the kernel already. And once we've got that, the time stats code is _also_ far simpler than doing it with ftrace would be. If anyone here has successfully debugged latency issues with ftrace, I'd really like to hear it. Again, for debugging latency issues you want something that can always be on, and that's not cheap with ftrace - and never mind the hassle of correlating start and end wait trace events, builting up histograms, etc. - that's all handled here. Cheap, simple, easy to use. What more could you want?