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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10B0DECAAD4 for ; Wed, 31 Aug 2022 21:38:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3EBB26B0072; Wed, 31 Aug 2022 17:38:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 374116B0073; Wed, 31 Aug 2022 17:38:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 215896B0074; Wed, 31 Aug 2022 17:38:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0C4D86B0072 for ; Wed, 31 Aug 2022 17:38:22 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D7E9D1214B4 for ; Wed, 31 Aug 2022 21:38:21 +0000 (UTC) X-FDA: 79861201602.19.2B86D94 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf21.hostedemail.com (Postfix) with ESMTP id 8D08A1C004A for ; Wed, 31 Aug 2022 21:38:20 +0000 (UTC) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-3321c2a8d4cso319670297b3.5 for ; Wed, 31 Aug 2022 14:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=6E7G6kJMNs5Us6NEnCBcT2HO6AKiMVb4bH/0vpPA/4U=; b=kAtSEhj7BWkD6SMRdd1t39qS+hQKouRS4qaWZ/zCB6oGUrFNrc2cBDYGv9jQ+MdF0J uxQpVt2B9TyIrWXDxJ2lE/5kGqIlaGR3KL1ZUwaFBmwiXzmcYyLDuUovokIJ5gP+z9l0 0yNTpmhlKudmxd6FSbYJNy7iPqg2dLLVGTx3y1J7sDru+O7/1p0gaM3HCn5KVfOBeHdH 7y51BAxidLFb2zqNvKSOOe8d+T3vU43qoJCQXNWAECkcBOpBA8zLImxhZz3blz38Sv8b A0VOTCczeuCjB41nhG0Ij40swVSwGGlY/9vVEbUAh5KhCZEJca7FVQKBTYw0uiQMXn3I 8fkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=6E7G6kJMNs5Us6NEnCBcT2HO6AKiMVb4bH/0vpPA/4U=; b=2cDiOLm2yEspWDhwQN1fgugmVM/iUS+feryguNXLpP1Cj9HgwoTQXERm3BcfC0Dlcr NMbPuufpcgXaCBnQRXqTBfspb5dHXlHRRUjv3C6E9YwnX7d9y6KIzHZN2m97hu+hPy92 DSfh4THBOiU1e3emz7hlFlk5fQeVnZLi3vJTgKojG5AwQu1H2LGSz1OsF2VrK/yedRIL v/S8KH+GtOZPxFcKk39GttGhVloN5YNZznDeQiU+6sNt2gPOuxft9Z46n5dXSx0hpHcG ZbJ4xly/hADGeORktptg5zZX4EYw+4ihiSEj1YEjytOO3yAAg1+kvYDLtSmHwOjQJqg2 uO3Q== X-Gm-Message-State: ACgBeo0xmCQtTWByLE364CF/oqovvhKVvIoLvG7eif98ubV0bQJ+UFMy K3e9K25PkyRENQ3tKX/NGD2LjL93Mvseu2v8txOpUA== X-Google-Smtp-Source: AA6agR71/tBRa7ErmmsvPBq7WvGBz62OVsrJ1soclQl+ncNHwGSnn/9fM5Y5i7G0A989GWlS6M/O5IwMTPKxavhJCfc= X-Received: by 2002:a81:85c3:0:b0:33d:a4d9:4599 with SMTP id v186-20020a8185c3000000b0033da4d94599mr19726685ywf.237.1661981899638; Wed, 31 Aug 2022 14:38:19 -0700 (PDT) MIME-Version: 1.0 References: <20220830214919.53220-1-surenb@google.com> <20220831084230.3ti3vitrzhzsu3fs@moria.home.lan> <20220831101948.f3etturccmp5ovkl@suse.de> <20220831190154.qdlsxfamans3ya5j@moria.home.lan> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 31 Aug 2022 14:38:08 -0700 Message-ID: Subject: Re: [RFC PATCH 00/30] Code tagging framework and applications To: Yosry Ahmed Cc: Kent Overstreet , Michal Hocko , Mel Gorman , Peter Zijlstra , Andrew Morton , Vlastimil Babka , Johannes Weiner , Roman Gushchin , Davidlohr Bueso , Matthew Wilcox , "Liam R. Howlett" , David Vernet , Juri Lelli , Laurent Dufour , Peter Xu , David Hildenbrand , Jens Axboe , mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, changbin.du@intel.com, ytcoode@gmail.com, Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Daniel Bristot de Oliveira , Valentin Schneider , Christoph Lameter , Pekka Enberg , Joonsoo Kim , 42.hyeyoo@gmail.com, Alexander Potapenko , Marco Elver , dvyukov@google.com, Shakeel Butt , Muchun Song , arnd@arndb.de, jbaron@akamai.com, David Rientjes , Minchan Kim , Kalesh Singh , kernel-team , Linux-MM , 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 Mailing List Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661981900; a=rsa-sha256; cv=none; b=6X5ER2YajJMuBL6mNxN+tdEuSszcGhspXooC4+rxl81+tCwyxcYYwbt1TAcb6Xpo/T5Z5u zs2UrZ2ljD2cPvFxbIoiNchF2VTk3RB4Zw5Unl5gAtUCH71qaYSWjoIxTR47siDShLYHVs d5YcbdqQY6EQcMsquDIiG3fgGThmT4A= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=kAtSEhj7; spf=pass (imf21.hostedemail.com: domain of surenb@google.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661981900; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6E7G6kJMNs5Us6NEnCBcT2HO6AKiMVb4bH/0vpPA/4U=; b=0XC6BA0gQOZUFnAqmu1REPGjeUqLF7Rit3UO54cvJu54Dzkz/jKZF6fI89ytcwCQ+uv+3b apaU9wBwq4kAHWOzm8mapoKu9qnZa0jzKer1ES0zGYHXd6H3E6jIicj26bSD91U6N/lMIX dKhT3QqGxnVfuQ/WxVhnSMEuNTeWnBA= X-Rspam-User: X-Stat-Signature: wf1s3myukswejyi7g3m47a8xpyg1i4ng X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 8D08A1C004A Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=kAtSEhj7; spf=pass (imf21.hostedemail.com: domain of surenb@google.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1661981900-854469 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 31, 2022 at 1:56 PM Yosry Ahmed wrote: > > On Wed, Aug 31, 2022 at 12:02 PM Kent Overstreet > wrote: > > > > 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? > > > > This is very interesting work! Do you have any data about the overhead > this introduces, especially in a production environment? I am > especially interested in memory allocations tracking and detecting > leaks. I had the numbers for my previous implementation, before we started using the lazy percpu counters but that would not apply to the new implementation. I'll rerun the measurements and will post the exact numbers in a day or so. > (Sorry if you already posted this kind of data somewhere that I missed)