Re: [PATCH] trace-cmd: Try alternate path for message cache

[Tzvetomir Stoyanov <tz.stoyanov@gmail.com>]

On Mon, Apr 4, 2022 at 6:04 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 4 Apr 2022 17:48:24 +0300
> Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote:
>
> > On Mon, Apr 4, 2022 at 5:35 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > On Mon, 4 Apr 2022 16:48:11 +0300
> > > Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote:
> > >
> > > > > > > Hi  Joel,
> > > > > > > That cache file is used for constructing the trace meta-data on the
> > > > > > > guest, before sending it to the host. Usually it is compressed, but it
> > > > > > > could be uncompressed in some cases (depending on the configuration) -
> > > > > > > and in that case it can grow up to a few megabytes. Using memfd is ok
> > > > > > > in most cases, but I'm wondering in the worst case - these few
> > > > > > > megabytes could be a problem, especially if the guest runs with a
> > > > > > > minimum amount of memory.
> > > > > > >
> > > > > >
> > > > > > Can you check that file size on your Android setup with that command,
> > > > > > it will force to not use compression on the guest trace file:
> > > > > >    trace-cmd <host trace options> -A <guest> <guest trace options>
> > > > > > --file-version 7 --compression none
> > > > >
> > > > > The file grows to 5.3MB with this. Is this really the common case
> > > > > though? If not, I would still prefer memfd tbh. Is that Ok with you?
> > >
> > > This is meta data right? Which means everything in here is in kernel memory
> > > anyway. kallsyms, events, etc. I do not believe that this will be an issue
> > > even uncompressed.
> > >
> > >
> > > > >
> > > >
> > > > There are two cases that could hit this:
> > > >  1. Using a " --compression none" flag on the guest file. We could
> > > > disable that flag and force trace file v7 always to use compression. I
> > > > cannot imagine a use case for uncompressed trace file, maybe only for
> > > > debug purposes ?
> > >
> > > Please no. I do have some machines that do not have zlib installed. I do
> > > not want to make it a requirement to have zlib for this use case. If we do
> > > not have memory, we could fall back to mktemp.
> >
> > Hi Steven,
> > I'm wondering how you run the latest trace-cmd on those machines ? As
> > these libraries are checked at compile time, this is a compile time
> > dependency - so the trace-cmd compiled with zlib support should not be
>
> It was compiled on the machine it ran on. I have to find which machine it
> was. I believe it was one of the gentoo or arch VMs that have very little
> installed. Bare minimum (you have to compile everything that is on it). But
> the trace-cmd I built did not have any compression support, which put it to
> --compression none by default. Without any compression libraries, it can
> still build.
>
> > able to run there ? That's why I think   " --compression none" could
> > be used only for debugging.
> > We could implement loading compression libraries dynamically to avoid
> > these compile time dependencyies, or add a compile flag to disable
> > compression support ?
>
> That is not needed. Do we really need to have compression always?
>

The current approach to use the best available compression algorithm
by default is good enough, but personally I prefer the logic with
dynamically loading of these libraries. That way we can use the same
binary, which will simplify the trace-cmd packaging. And the first PoC
implementation of compression support was that way :)

> -- Steve



-- 
Tzvetomir (Ceco) Stoyanov
VMware Open Source Technology Center