On Mon, Apr 4, 2022 at 6:04 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Mon, 4 Apr 2022 17:48:24 +0300 > Tzvetomir Stoyanov <tz.stoyanov@xxxxxxxxx> wrote: > > > On Mon, Apr 4, 2022 at 5:35 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > > > On Mon, 4 Apr 2022 16:48:11 +0300 > > > Tzvetomir Stoyanov <tz.stoyanov@xxxxxxxxx> 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
|