<div dir="ltr">Hello developers, <div class="gmail_quote"><div dir="ltr"> Merry Xmas and happy new year. I would like to disturb you little bit about the journal behavior. We are doing some embedded systems with high boot performance requirement. First, thanks to systemd the startup configuration is no more a sophisticated job. Still, we faced some problems with journald in our work. We found the CPU latency for each log is a bit higher than we expected, especially when we have thousands of logs during startup, which in fact delays our early applications during the startup. In a test, we were continuous logging information using different methods which journald support, for example syslog. We found that more than half of the total CPU cycles (from the flame graph we got) are used by function cg_pid_get_path_shifted(). I am not sure why this function is little bit too heavy. This function seems to be used from two places: The first is to test the journal rate limit. In my understanding, if we turn off the limit, ie. set it to zero. The function is not needed to be called. In fact the check whether it is disabled comes later, which makes the function cg_pid_get_path_shifted() still being called. Maybe just by preponing the check we could economize CPU cycles. The second is to collect the metadata, especially the cgroup information. We've tried to bypass the function in this part of source code and are able to accelerate the startup. One effect is that we lost some metadata in the journal, like _COMM= _EXE= _CMDLINE= _SYSTEMD_CGROUP= _SYSTEMD_UNIT= _SYSTEMD_SLICE= These information are not critical in our project setting thus we can accept the loss of these data. I would like to get advice from you, If there are any other risks, from which we may get into trouble. And maybe it is an option if we could have an option in the runtime configuration to select which kind of metadata are required to avoid unnecessary latency. Thanks for any hints. Regards Шуангистан </div> </div></div>