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 43EB8C6FA82 for ; Thu, 1 Sep 2022 23:36:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235163AbiIAXgk (ORCPT ); Thu, 1 Sep 2022 19:36:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235124AbiIAXgi (ORCPT ); Thu, 1 Sep 2022 19:36:38 -0400 Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 363D6A4056 for ; Thu, 1 Sep 2022 16:36:36 -0700 (PDT) Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-3413ad0640dso2006627b3.13 for ; Thu, 01 Sep 2022 16:36:36 -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=5pc1SgOf8Owl6sShRuirH1QWrWtPdJIgt3qepozMpkE=; b=QPtBN+jZZjR+fJQ+f+TgwZFy47TE1rR8gr1i8rB6mNu2nigO0JdCAAjMoUMaOVDYnd PiHulcKqQEwjGxjDADddZzXOUg5TYr/Y37FY0mLnlnZh9oqDpuWtb21NiE8K+MvKfMRy 5X2JycO4tSVca0qzV4Yx+TBoNNmpSKbKbCfgMYwA7K5CFp+VszB2v0xi3C2mZ4ZpAFpk VGoNBkpcZXTh7tuDysjYq/uSfLBayYSiQwhTFjGtzTF3WK2rRSdy71A7E9l9S18szgn+ hw0Qy3jClG1SDJCQ3AEQ+kyF5TgjSC7WKM1l7PFAPgZmXyevNIAyCBELnZOO/Zt3zo42 CuWw== 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=5pc1SgOf8Owl6sShRuirH1QWrWtPdJIgt3qepozMpkE=; b=f5SAyniSzMORj2w672MigKTQNJcN5XhPZixJCjNW2AQNeS9PS0XPQbOQwTj9Vr3qs1 U6w/y6rffHYhU7bVbB4/6lP/0VhC2ynFVQH7RIy6ncBrebgOMu/eyiUAC1ITsX/XKiHi 9SoE/em2JGO9ABrmxcDqdgk0hntX3jYz0ynS3wIQV2qtnGh9rX8k0sznc1Jqdd7QGwmr QPM0nT6gyeoovBkquBmtVwdc+cdQMAuMOaVpjphU/kG3GOYLvll1p2Ew9FQY2NMvlf9F PTRNj5wA5s07ipq3T6U1V1UCP4auoN+1kGF8V2wRINqRcohwxGu2Bt5yS0ZYDzTNrGIe yWOA== X-Gm-Message-State: ACgBeo1HaYnTj9+xMqU+x3916QFoCZoXdLX8JWP2Osz4E3V3ayJUBQBW WYvxImAFUzyi6FcOCAqQZVWBw1MaiTvtul4g5Mc+bA== X-Google-Smtp-Source: AA6agR6KXscPx8LI6183+UcafzSZSBU2Me59d4tUPUgAjsDK3Cl3Xie4I9qREIbKygjbUBWHlz0pZa86okKUwdzJLtw= X-Received: by 2002:a0d:c981:0:b0:330:dc03:7387 with SMTP id l123-20020a0dc981000000b00330dc037387mr25216063ywd.380.1662075395130; Thu, 01 Sep 2022 16:36:35 -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> <20220901223720.e4gudprscjtwltif@moria.home.lan> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 1 Sep 2022 16:36:23 -0700 Message-ID: Subject: Re: [RFC PATCH 00/30] Code tagging framework and applications To: Roman Gushchin Cc: Kent Overstreet , Yosry Ahmed , Michal Hocko , Mel Gorman , Peter Zijlstra , Andrew Morton , Vlastimil Babka , Johannes Weiner , 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 , Dmitry Vyukov , 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" Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Thu, Sep 1, 2022 at 3:54 PM Roman Gushchin wrote: > > On Thu, Sep 01, 2022 at 06:37:20PM -0400, Kent Overstreet wrote: > > On Thu, Sep 01, 2022 at 03:27:27PM -0700, Roman Gushchin wrote: > > > On Wed, Aug 31, 2022 at 01:56:08PM -0700, Yosry Ahmed wrote: > > > > 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. > > > > > > +1 > > > > > > I think the question whether it indeed can be always turned on in the production > > > or not is the main one. If not, the advantage over ftrace/bpf/... is not that > > > obvious. Otherwise it will be indeed a VERY useful thing. > > > > Low enough overhead to run in production was my primary design goal. > > > > Stats are kept in a struct that's defined at the callsite. So this adds _no_ > > pointer chasing to the allocation path, unless we've switch to percpu counters > > at that callsite (see the lazy percpu counters patch), where we need to deref > > one percpu pointer to save an atomic. > > > > Then we need to stash a pointer to the alloc_tag, so that kfree() can find it. > > For slab allocations this uses the same storage area as memcg, so for > > allocations that are using that we won't be touching any additional cachelines. > > (I wanted the pointer to the alloc_tag to be stored inline with the allocation, > > but that would've caused alignment difficulties). > > > > Then there's a pointer deref introduced to the kfree() path, to get back to the > > original alloc_tag and subtract the allocation from that callsite. That one > > won't be free, and with percpu counters we've got another dependent load too - > > hmm, it might be worth benchmarking with just atomics, skipping the percpu > > counters. > > > > So the overhead won't be zero, I expect it'll show up in some synthetic > > benchmarks, but yes I do definitely expect this to be worth enabling in > > production in many scenarios. > > I'm somewhat sceptical, but I usually am. And in this case I'll be really happy > to be wrong. > > On a bright side, maybe most of the overhead will come from few allocations, > so an option to explicitly exclude them will do the trick. > > I'd suggest to run something like iperf on a fast hardware. And maybe some > io_uring stuff too. These are two places which were historically most sensitive > to the (kernel) memory accounting speed. Thanks for the suggestions, Roman. I'll see how I can get this done. I'll have to find someone with access to fast hardware (Android is not great for that) and backporting the patchset to the supported kernel version. Will do my best. Thanks, Suren. > > Thanks! > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >