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 X-Spam-Level: X-Spam-Status: No, score=-13.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A78C0C432C0 for ; Tue, 3 Dec 2019 02:48:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5ECAA20684 for ; Tue, 3 Dec 2019 02:48:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="toDvzKWh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5ECAA20684 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E74CB6B0007; Mon, 2 Dec 2019 21:48:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DFD7B6B0008; Mon, 2 Dec 2019 21:48:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC5266B000A; Mon, 2 Dec 2019 21:48:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id B1E7A6B0007 for ; Mon, 2 Dec 2019 21:48:51 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 5AF8F8248D51 for ; Tue, 3 Dec 2019 02:48:51 +0000 (UTC) X-FDA: 76222297662.22.burn14_3027102127c25 X-HE-Tag: burn14_3027102127c25 X-Filterd-Recvd-Size: 9743 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Dec 2019 02:48:50 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id g17so1812420wro.2 for ; Mon, 02 Dec 2019 18:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7nky1mS0efubhnwiM4yI3kYFC/Eyd5zTtwkh3pTxWDo=; b=toDvzKWhfEb7D2qCIPr0Wd0qu9RBgmvCKmrPP95i8re471S+qHcaoG3wtHSPXx5MdN YWCUv+R9oKVzmmGfjWf1MFTg1e7MiFYyXhi4KGxJl0Fx8VTyL9Cdv0bTjFv5JuSomSlm VQKzfzi5kK4dck4aQ4T1bB90hHljWBCnUUmatggApVrB4euFwlUfUVtWG1QJRIwCO1xi tViuu8nAW3fEXJQySoaQieyN2fwB9xgvauaXErC4I7ZadTccnmxXUCvKa+fZeYZDlzv9 A7mLSWEogtrSQoH7U7imNmlTWBWvG/U+i6NoSF9L+WXBRMGDBRhk4nR00Dt+Rc4NvlId uCIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7nky1mS0efubhnwiM4yI3kYFC/Eyd5zTtwkh3pTxWDo=; b=NaJvr2eiuS4CHBrTmOpXQIeyOloLOJh6KeSvQCzjENTF/X/h7kk0CYGPOrMTk5dzSE GlK4XL4T2env+6NtGiSap1vaC1t86+FHMlGmSvp7x01+UoPB/BYpZTgS2eXZ/h3R8Cgg 2yFYg2aaCi3+kdDGLnFmEn6289wSKNgYIIhrPgEy41DqmAXy9zDKAno3dbk9HUKH3ibD BJ9wIAg6IUkC/oTiVZutx80OFY19Q8T6j4h2jCusifz44mHwr3rv3sC/yjEbS2t2cOVg duOeiLwaZO9cc95nfQTSiN21y1FusVuH0xnoPi8tMQ04PhMk3tvEnXDqkyzBsMVpYYic PT1w== X-Gm-Message-State: APjAAAVxPI8fnS2yuuwaj0kx7kU0nfBLyfvYKraaK9HclWs/Yz6Wh1TY l/esBPWhIRcor1Myi/gNCEkuteafaRQXgRGhJPzycA== X-Google-Smtp-Source: APXvYqzGPX5Rh5vC6ucZe7xjG5YUFiTVwgkgVDUhqXSCvTPz7Al53jwnAG412sntz/TL160uZ/+Bb3b1MbFzvFhJm2s= X-Received: by 2002:adf:fcc4:: with SMTP id f4mr2342251wrs.247.1575341328812; Mon, 02 Dec 2019 18:48:48 -0800 (PST) MIME-Version: 1.0 References: <20191201015030.MR-ux4mV1%akpm@linux-foundation.org> <20191202121415.1e64a461@gandalf.local.home> <20191202211345.GE17234@google.com> <20191202165601.42366c21@gandalf.local.home> <20191202234514.GR17234@google.com> <20191202185324.30b502bb@gandalf.local.home> In-Reply-To: <20191202185324.30b502bb@gandalf.local.home> From: Primiano Tucci Date: Tue, 3 Dec 2019 02:48:37 +0000 Message-ID: Subject: Re: [patch 026/158] mm: emit tracepoint when RSS changes To: Steven Rostedt Cc: Joel Fernandes , Andrew Morton , aneesh.kumar@linux.ibm.com, Carmen Jackson , dan.j.williams@intel.com, Daniel Colascione , jglisse@redhat.com, linux-mm@kvack.org, Mayank Gupta , mhocko@suse.com, minchan@kernel.org, mm-commits@vger.kernel.org, rcampbell@nvidia.com, Tim Murray , torvalds@linux-foundation.org, vbabka@suse.cz, willy@infradead.org, Mathieu Desnoyers Content-Type: text/plain; charset="UTF-8" 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 Mon, Dec 2, 2019 at 11:53 PM Steven Rostedt wrote: On Mon, 2 Dec 2019 18:45:14 -0500 Joel Fernandes wrote: > > I would love for that to happen but I don't develop Perfetto much. If I am > writing a tool I will definitely give it a go from my side. CC'ing Perfetto's > lead developer Primiano -- I believe you have already met Primiano at a > conference before as he mentioned it to me that you guys met. I also believe > this topic of using a common library was discussed before, but something > about licensing came up. Oh hello again! > libtraceevent is under LGPL, is that an issue? Unfortunately yes, it is :/ Our process for incorporating GPL or LGPL code makes Perfetto [1] (which is Apache-2 licensed) problematic for us and recursively for other projects that depend on us. For context, Perfetto is a cross-platform tracing project based on shmem and protobuf, shipped on production devices and used by other app-developer-facing tools (e.g. [6, 7]). It deals with both: (1) pure userspace-to-userspace tracing (on all major OSs). (2) kernel tracing via ftrace/tracefs (only on Linux/Android). https://docs.perfetto.dev/ explains it a bit more. Today Perfetto is embedded and used both by Chrome [2] and Android platform [3]. For both projects, pulling LGPL-licensed code is cumbersome process-wise: It would require us to put mechanism in place to guarantee that the relevant LGPL dependencies don't get accidentally linked in any production binary but only used for the standalone offline tools to analyze traces. Such process is unfortunately very expensive to setup and maintain for us and for the projects that depend on us. I don't want to start an ideological battle about licensing. To be clear, I don't have any issues with LGPL, nor I think there's anything inherently wrong with it. Just, it makes things too complicated when a smaller sub-project like ours is embedded in larger projects. Anyhow, beyond licensing, the principle of grabbing the format files on-device and bundling them as part of the trace is also problematic for us on Android for technical reasons (mainly interoperability with other tools that depend on Perfetto). >From my viewpoint, it would be great if Linux treated the individual fields of ftrace events as an ABI, given that ftrace events are exposed in their binary form to userspace through tracefs (which is something I'm extremely grateful for). We use ftrace_pipe_raw through Perfetto in Android since 2017 and it has been working great with the exception of a few cases, mainly enums (see below). I'd love if we could solve the enum problem in a way that didn't involve running a C-preprocessor-alike runtime on the format files, regardless of licensing. Unfortunately I don't have any docs that describe the Perfetto <> ftrace interop in great details. I apologize for that. I'll fix it soon but in the meanwhile I'll try to do my best to summarize this part of Perfetto here: Our ftrace-interop code read()s the binary per_cpu/*/trace_pipe_raw, very similarly in spirit to what trace_cmd does. However, unlike trace_cmd, we convert the trace event stream into protobufs (e.g., [4]), doing binary-to-binary conversions (ftrace raw pipe -> protobuf) at runtime, asynchronously, on the device being traced. The way we deal with format files in Perfetto is twofold: 1) We have an archive of known format files for the most common kernels we care about. From this archive we generate protobuf schema files like [4] at Perfetto-compile-time (which is != compile time of the target device's kernel). At runtime, on-device, we read the format files from tracefs and we merge the compile-time knowledge (about messages and field names) with the ABI described by tracefs' format files (message IDs, field types and offsets). We make the following assumption about the ABI of raw ftrace events: - We do *not* rely on message IDs being stable. - We do *not* rely on the field offset to be stable. - We do *not* rely on the size and length of int fields to be stable. - We do *not* assume the presence of any field. - We can detect if a field's type doesn't match anymore (e.g. a string became an int) and ignore the field in that case. - We only deal with fields whose name matches what known at compile-time. This allows us to turn the raw ftrace into a binary-stable protobuf (modulo some fields that might be missing) and allows us to play some other tricks to reduce the size of the trace (e.g. intern/dedupe thread names). 2) We have a generic schema [5] to transcode ftrace events that we didn't know at Perfetto-compile-time. This allows us to deal with both ftrace events introduced by future kernel versions or as a fallback for events in 1) where we detect ABI mismatches at runtime. The downside of this generic schema is that the cost of each event, in terms of trace-size, is significantly higher. There is a point where both 1 and 2 become problematic for us, and this is enums and, more in general, any ftrace field depends on macro expansions (which turns out to be mainly enums, in practice). For instance, the gfp_flags of ftrace events directly reflects the internal enum values, which are not stable across kenrnel versions. We had to come up with an internal map to catch up with the various kernel versions. There are few other cases like gfp_flags but they are quite rare and we ended up not needing those events, at least until now. Beyond this, ingesting the raw trace events from ftrace raw pipes it has been great for all other events without requiring any other parsing library Super thanks for all the hard work on developing and maintaining ftrace. Happy to discuss more on IRC, email or VC if you want to know more, Primiano. [1] https://docs.perfetto.dev [2] https://cs.chromium.org/chromium/src/third_party/perfetto/?q=f:perfetto&sq=package:chromium&dr [3] https://android.googlesource.com/platform/external/perfetto/ [4] https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/protos/perfetto/trace/ftrace/sched.proto [5] https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/protos/perfetto/trace/ftrace/generic.proto [6] https://github.com/google/gapid/ [7] https://developers.google.com/web/tools/chrome-devtools