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 48008ECAAD1 for ; Thu, 1 Sep 2022 07:37:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DCE4F6B0073; Thu, 1 Sep 2022 03:37:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D7D256B0074; Thu, 1 Sep 2022 03:37:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1F816B0075; Thu, 1 Sep 2022 03:37:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B23556B0073 for ; Thu, 1 Sep 2022 03:37:04 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7EA544097F for ; Thu, 1 Sep 2022 07:37:04 +0000 (UTC) X-FDA: 79862710368.08.409CAC9 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 3265940042 for ; Thu, 1 Sep 2022 07:37:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662017823; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w/uTT8lnpogUVhwkYNDxdhGZzOyBXG3eWWImkgPiyoM=; b=DgayC5dyfaeGXWgqcGu/YcLeWOxlSxKhLpPoQminM/M3pGbY73WxztkrhpaiegTmoZhNJ8 izs+WXb28e8YU80Odx6KsPd3FU1KYrTVx+iSPIcqidvGBQAiflWSAlmYLqzBNBPGWuxK7P 3MPhtjSRmJCu6jTPnEFblE1h4PJh5q8= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-38-Ba3ODaLIMjycfDjT7OOu_g-1; Thu, 01 Sep 2022 03:37:02 -0400 X-MC-Unique: Ba3ODaLIMjycfDjT7OOu_g-1 Received: by mail-ed1-f71.google.com with SMTP id z20-20020a05640235d400b0043e1e74a495so11242147edc.11 for ; Thu, 01 Sep 2022 00:37:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=w/uTT8lnpogUVhwkYNDxdhGZzOyBXG3eWWImkgPiyoM=; b=NB/I+4eTdr+LM2Jr8hBDo8kHPLcGiQMpe08hs+aHov01LzQXAtroPtniVftMU4iZX3 Ti8+7Jm62Oo9g7I434H5pE8Ue6borAOtz4hMmimASIshSQNqsAEnd2QQxGiaOmU+t9Au MRcZRhF0Cew3WqjvgWEtDnyStdTBAqZeDyMRPe2jnHZ521hA9PzZzO15U2vMlmasERDu hHp3lwh8i9it75lANIQkSgHpi502p1NQRg1+U63fMWdsTTFUSzlzpQmSdoUm0dapdJ5y UgFeR0aG00HdfDWasmXSN7/lX2HG4sLOwgf9NL1J6OqJpWO5m7dUPdxgpknJ3K7mUk6Q xJXg== X-Gm-Message-State: ACgBeo09UFrSqtORXVYUe/amdXnGH6sqWC+DyO6pYMtEk6kUP9bwAiA5 BR5UYfw5827AIiQCWci+7vteyd2j+N5fYam6jSPG1UXOg/BgSLStKFIzji2J5KWDVMYLFyvQnBh CAJo6TkuvVAs= X-Received: by 2002:aa7:d90e:0:b0:447:986d:b71e with SMTP id a14-20020aa7d90e000000b00447986db71emr27210690edr.235.1662017821488; Thu, 01 Sep 2022 00:37:01 -0700 (PDT) X-Google-Smtp-Source: AA6agR6JkW4ed1WqDsotybL6CAAiG40VbkLtzaIPBaAypGnjlWDX5j26Jhqen11PzZwUzZ8Rc1KOjQ== X-Received: by 2002:aa7:d90e:0:b0:447:986d:b71e with SMTP id a14-20020aa7d90e000000b00447986db71emr27210669edr.235.1662017821253; Thu, 01 Sep 2022 00:37:01 -0700 (PDT) Received: from [192.168.0.198] (host-87-8-60-205.retail.telecomitalia.it. [87.8.60.205]) by smtp.gmail.com with ESMTPSA id u24-20020aa7d998000000b0043a61f6c389sm898086eds.4.2022.09.01.00.36.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Sep 2022 00:37:00 -0700 (PDT) Message-ID: <37a66a8d-859d-5a8b-e298-d0c32e2028e7@redhat.com> Date: Thu, 1 Sep 2022 09:36:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [RFC PATCH 00/30] Code tagging framework and applications To: Peter Zijlstra , Kent Overstreet Cc: Mel Gorman , 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, 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 References: <20220830214919.53220-1-surenb@google.com> <20220831084230.3ti3vitrzhzsu3fs@moria.home.lan> <20220831101948.f3etturccmp5ovkl@suse.de> <20220831155941.q5umplytbx6offku@moria.home.lan> From: Daniel Bristot de Oliveira In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DgayC5dy; spf=pass (imf11.hostedemail.com: domain of bristot@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bristot@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662017824; a=rsa-sha256; cv=none; b=JHaoVNgIda4pC04ccddJuYBFbSw1L2YlpnACllczLqUnIhPuO3Tq1TVXdNjuca2fRjgUWz KoUi5xYrJtJTTwQUUVtYyng3DUEfQvGRwq7OjAn5kLgz9L9oXm4npsIB9iG1FJ0tKGKOh1 dBXyx75pMoMWU8olUSdq8AP4jwlgvis= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662017824; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=w/uTT8lnpogUVhwkYNDxdhGZzOyBXG3eWWImkgPiyoM=; b=XHIomkdSdrJNlUY3QVJF3iKb2umHjLR3gTKjWXUvUwzWA8sDAxb4cQDcpN8AfMzl/PVtzz 6QEh/C/AK4K7CoR3V17E2HrfK163ARukVIndIpn9DAjd27QhO+5hY24lyjewA5YgeMDmKa SmYNkydohCOh7pWjVxn2HmOtytIsYIk= Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DgayC5dy; spf=pass (imf11.hostedemail.com: domain of bristot@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bristot@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Stat-Signature: 7yp1tfi7gyknwn3jsjxcfts1kpt9jxgm X-Rspamd-Queue-Id: 3265940042 X-Rspamd-Server: rspam09 X-HE-Tag: 1662017824-371342 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 9/1/22 09:05, Peter Zijlstra wrote: >> Also, ftrace can drop events. Not really ideal if under system load your memory >> accounting numbers start to drift. > You could attach custom handlers to tracepoints. If you were to replace > these unconditional code hooks of yours with tracepoints then you could > conditionally (say at boot) register custom handlers that do the > accounting you want. That is strategy in RV (kernel/trace/rv/). It is in C, but I am also adding support for monitors in bpf. The osnoise/timerlat tracers work this way too, and they are enabled on Fedora/Red Hat/SUSE... production. They will also be enabled in Ubuntu and Debian (the interwebs say). The overhead of attaching code to tracepoints (or any "attachable thing") and processing data in kernel is often lower than consuming it in user-space. Obviously, when it is possible, e.g., when you respect locking rules, etc. This paper (the basis for RV) shows a little comparison: https://bristot.me/wp-content/uploads/2019/09/paper.pdf By doing so, we also avoid problems of losing events... and you can also generate other events from your attached code. (It is also way easier to convince a maintainer to add a tracepoints or a trace events than to add arbitrary code... ;-) -- Daniel