258190a0d5
The ret_size result is a bit of an awkward optimization that in a sense enables bypassing the mmap-cache API, while encouraging duplication of logic it already implements. It's only utilized in one place; journal_file_move_to_object(), apparently to avoid the overhead of remapping the whole object again once its header, and thus its actual size, is known. With mmap-cache's context cache, the overhead of simply re-getting the object with the now known size should already be negligible. So it's not clear what benefit this brings, unless avoiding some function calls that do very little in the hot context-cache hit case is of such a priority. There's value in having all object-sized gets pass through mmap_cache_get(), as it provides a single entrypoint for instrumentation in profiling/statistics gathering. When journal_file_move_to_object() bypasses getting the full object size, you don't capture the full picture on the mmap-cache side in terms of object sizes explicitly loaded from a journal file. I'd like to see additional accounting in mmap_cache_get() in a future commit, taking advantage of this change. |
||
---|---|---|
.github | ||
.lgtm/cpp-queries | ||
.mkosi | ||
catalog | ||
coccinelle | ||
docs | ||
factory/etc | ||
hwdb.d | ||
man | ||
modprobe.d | ||
network | ||
po | ||
presets | ||
rules.d | ||
semaphoreci | ||
shell-completion | ||
src | ||
sysctl.d | ||
sysusers.d | ||
test | ||
tmpfiles.d | ||
tools | ||
travis-ci | ||
units | ||
xorg | ||
.clang-format | ||
.ctags | ||
.dir-locals.el | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.lgtm.yml | ||
.mailmap | ||
.travis.yml | ||
.vimrc | ||
.ycm_extra_conf.py | ||
LICENSE.GPL2 | ||
LICENSE.LGPL2.1 | ||
Makefile | ||
NEWS | ||
README | ||
README.md | ||
TODO | ||
azure-pipelines.yml | ||
configure | ||
meson.build | ||
meson_options.txt | ||
mkosi.build | ||
zanata.xml |
README.md
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.