This is a rewrite of the hashmap implementation. Its advantage is lower
memory usage.
It uses open addressing (entries are stored in an array, as opposed to
linked lists). Hash collisions are resolved with linear probing and
Robin Hood displacement policy. See the references in hashmap.c.
Some fun empirical findings about hashmap usage in systemd on my laptop:
- 98 % of allocated hashmaps are Sets.
- Sets contain 78 % of all entries, plain Hashmaps 17 %, and
OrderedHashmaps 5 %.
- 60 % of allocated hashmaps contain only 1 entry.
- 90 % of allocated hashmaps contain 5 or fewer entries.
- 75 % of all entries are in hashmaps that use trivial_hash_ops.
Clearly it makes sense to:
- store entries in distinct entry types. Especially for Sets - their
entries are the most numerous and they require the least information
to store an entry.
- have a way to store small numbers of entries directly in the hashmap
structs, and only allocate the usual entry arrays when the direct
storage is full.
The implementation has an optional debugging feature (enabled by
defining the ENABLE_HASHMAP_DEBUG macro), where it:
- tracks all allocated hashmaps in a linked list so that one can
easily find them in gdb,
- tracks which function/line allocated a given hashmap, and
- checks for invalid mixing of hashmap iteration and modification.
Since entries are not allocated one-by-one anymore, mempools are not
used for entries. Originally I meant to drop mempools entirely, but it's
still worth it to use them for the hashmap structs. My testing indicates
that it makes loading of units about 5 % faster (a test with 10000 units
where more than 200000 hashmaps are allocated - pure malloc: 449±4 ms,
mempools: 427±7 ms).
Here are some memory usage numbers, taken on my laptop with a more or
less normal Fedora setup after booting with SELinux disabled (SELinux
increases systemd's memory usage significantly):
systemd (PID 1) Original New Change
dirty memory (from pmap -x 1) [KiB] 2152 1264 -41 %
total heap allocations (from gdb-heap) [KiB] 1623 756 -53 %
Previously when a log message grew beyond the maximum AF_UNIX/SOCK_DGRAM
datagram limit we'd send an fd to a deleted file in /dev/shm instead.
Because the sender could still modify the file after delivery we had to
immediately copy the data on the receiving side.
With memfds we can optimize this logic, and also remove the dependency
on /dev/shm: simply send a sealed memfd around, and if we detect the
seal memory map the fd and use it directly.
When running sysusers we would clobber file ownership and permissions
on the files /etc/passwd, /etc/group and /etc/[g]shadow.
This simply preserves the ownership and mode if existing files are
found.
The docs don't clarify what is expected, but I don't see any reason
why --type should be ignored.
Also restucture the compund conditions into separate clauses for
easier reading.
A combination of commits f3c80515c and 79d80fc14 cause nspawn to
silently fail with a commandline such as:
# systemd-nspawn -D /build/extra-x86_64 --bind=/usr
strace shows the culprit:
[pid 27868] writev(2, [{"Failed to create mount point /build/extra-x86_64/usr: File exists", 82}, {"\n", 1}], 2) = 83
For now, it's systemd itself that parses the options string, but as soon
as util-linux' swapon can take the option string directly with -o we
should pass it on unmodified.
In some cases it is preferable to ship system images with a pre-generated
binary hwdb database, to avoid having to build it at runtime, avoid shipping
the source hwdb files, or avoid storing large binary files in /etc.
So if hwdb.bin does not exist in /etc/udev/, fall back to looking for it in
UDEVLIBEXECDIR. This keeps the possibility to add files to /etc/udev/hwdb.d/
and re-generating the database which trumps the one in /usr/lib.
Add a new --usr flag to "udevadm hwdb --update" which puts the database
into UDEVLIBEXECDIR.
Adjust systemd-udev-hwdb-update.service to not generate the file in /etc if we
already have it in /usr.
While GNOME/KDE are generally capitalized, systemd tools generally are
not, hence let's not start doing so in the XDG_CURRENT_SESSION
environment variable.
UID or GID of 0 is valid, so we cannot use that to distinguish whether
calls to sd_bus_creds_get_* succeeded, and the return value from the
function is the only way to know about missing fields. Print "n/a" if
the fields are missing.
CID #1238779
The system start timeout as previously implemented would get confused by
long-running services that are included in the initial system startup
transaction for example by being cron-job-like long-running services
triggered immediately at boot. Such long-running jobs would be subject
to the default 15min timeout, esily triggering it.
Hence, remove this again. In a subsequent commit, introduce per-target
job timeouts instead, that allow us to control these timeouts more
finegrained.
Michal Schmidt
Lennart Poettering
Colin Guthrie
Zbigniew Jędrzejewski-Szmek
Dave Reisner
Kay Sievers
Susant Sahani
Tom Gundersen
Umut Tezduyar Lindskog
WaLyong Cho
Martin Pitt
Timofey Titovets