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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no 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 EAB3FC4743C for ; Mon, 21 Jun 2021 23:10:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D508461164 for ; Mon, 21 Jun 2021 23:10:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231303AbhFUXM6 (ORCPT ); Mon, 21 Jun 2021 19:12:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:32956 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231246AbhFUXM5 (ORCPT ); Mon, 21 Jun 2021 19:12:57 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5B57160FDB; Mon, 21 Jun 2021 23:10:42 +0000 (UTC) Date: Mon, 21 Jun 2021 19:10:40 -0400 From: Steven Rostedt To: "Tzvetomir Stoyanov (VMware)" Cc: linux-trace-devel@vger.kernel.org Subject: Re: [PATCH v6 21/45] trace-cmd library: Add compression of the option section of the trace file Message-ID: <20210621191040.6ba78839@gandalf.local.home> In-Reply-To: <20210614075029.598048-22-tz.stoyanov@gmail.com> References: <20210614075029.598048-1-tz.stoyanov@gmail.com> <20210614075029.598048-22-tz.stoyanov@gmail.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-trace-devel@vger.kernel.org On Mon, 14 Jun 2021 10:50:05 +0300 "Tzvetomir Stoyanov (VMware)" wrote: > Comperss the option section of the trace file. This section is not big > currently and compressing it does not reduce significantly the size of > the file. This could be useful in the future as new options can be > added, storing a potentially huge amount of data. I'm not sure we want to bother doing this. New options should never be large, and if they are, then the option itself can be compressed when created. What good reason is there to compress the options? I believe this is just adding more complexity than needed. -- Steve