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. > 2. If, for some reason, there are no supported compression libraries > on the guest. Trace-cmd supports libz and libzstd, I believe both are > widely available. Theoretically it could be possible to have some > minimalistic VM image without any of these libraries. Not theoretical ;-) > What are the advantages of using memfd instead of temp file, is it > only for performance ? Usually collecting trace metadata is not > performance critical, as it is done before starting the trace. > I think that the best solution is to use memfd in case the guest file > is compressed and switch back to a temp file in case of a > not-compressed file. Yeah, we could use memfd if compressed and temp if not. Luckily, this isn't something exposed across the API so we should be able to experiment with various implementations, and if people complain about one (like Joel did for Android), we can try something else. -- Steve
|