| Age | Commit message (Collapse) | Author |
|---|
|
This is currently very hacky and unfinished, but does enough for
some performance comparisons against a zstd-using journalctl --verify
that has been hacked to return early after the first pass.
It's currently rather leaky, the whole per-object-dispatch thingy
is illuminating a thunk_h shortcoming and forcing addressing the
issue... soon.
|
|
This gives some visibility into EntryArrayObject duplication and
utilization statistics.
It's not the tidiest of code, just something I slapped together
last night.
|
|
This writes a .layout file for every opened journal, which
describes the sequential object layout for the respective
journal.
Sample output:
```
Layout for "user-1000.journal"
Legend:
? OBJECT_UNUSED
d OBJECT_DATA
f OBJECT_FIELD
e OBJECT_ENTRY
D OBJECT_DATA_HASH_TABLE
F OBJECT_FIELD_HASH_TABLE
A OBJECT_ENTRY_ARRAY
T OBJECT_TAG
|N| object spans N page boundaries (page size used=4096)
| single page boundary
+N N bytes of alignment padding
+ single byte alignment padding
F|5344 D|448|1834896 d81+7 f50+6 d74+6 f48 d82+6 f55+ d84+4 f57+7 d80 f50+6 d122+6 f47+ d74+6 f44+4 d73+7 f44+4 d70+2 f44+4 d72 f45+3 d76+4 f44+4 d75+5 f48 d90+6 f54+2 d80 f54+2 d84+4 f55+ d123+5 f55+ d82+6 f56 d87+ f58+6 d93+3 f53+3 d|94+2 f54+2 d91+5 f59+5 d119+ f62+2 d107+5 f66+6 d105+7 f48 d108+4 f51+5 d82+6 f49+7 e480 A56 d80 d104 d74+6 d73+7 d107+5 e480 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 d97+7 d107+5 e|480 A56 A56 A56 d136 d107+5 e480 A56 d74+6 d148+4 d107+5 e480 A88 d107+5 e480 A88 A88 A88 A56 A88 A88 A88 A88 A88 A88 A88 A88 A88 A88 A|88 A88 A88 A88 A88 A88 A88 d80 d74+6 d107+5 e480 A88 A56 d107+5 e480 A56 A56 A56 d107+5 e480 A56 d107+5 e480 A88 A56 A56 d107+5 e|480 d80 d74+6 d107+5 e480 d97+7 d107+5 e480 A232 A88 A56 A56 d142+2 d107+5 e480 A232 A232 A232 A232 A232 A|232 A232 A232 A232 A232 A232 A232 A232 A232 A232 A232 A232 A232 A232 A232 d107+5 e480 d107+5 e|480 d80 d74+6 d107+5 e480 A232 d107+5 e480 A56 A56 d107+5 e480 d107+5 e480 d107+5 e304 d80 d74+6 d107+5 e|480 d107+5 e480 A56 A56 d107+5 e480 A232 d107+5 e480 d107+5 e480 A88 d80 d74+6 d107+5 e480 A88 d107+5 e|480 A56 A56 d107+5 e480 d107+5 e480 A88 A88
```
This provides insight into the distribution of object types, how
much space is spent on alignment padding, how frequently objects
land on page boundaries - something preferably avoided especially
for small objects near a boundary.
In the above example, we can immediately make the observation
that early in the journal there are interleaved data and field
objects, and this cluster of the initially added data and field
objects gets torn by a page boundary. It's possible if they
weren't interleaved when adding an entry and its respective data
+ fields, fitting all the early (common) data objects within a
single page might confer some performance gain. The field
objects aren't currently used by data object heavy operations, it
doesn't make much sense to have them polluting the area of the
initially added data objects or really any otherwise clustered
data objects.
|
|
This is a very quick and dirty experimental hack written in some
sort of bastard continuation-passing style in C w/io_uring using
journal-file introspection and manipulation duty as an excuse for
its existence.
Consider this unfinished prototype quality code.
|
