@jayzmh: major invasive change to ... RPM? or something else?
I'll happily write the code for rpm.org RPM if you wish. I fail to see how
reverting to what RPM used to do (i.e. use mmap with MADV_DONTNEED and most
importantly for you using msync(MS_ASYNC) which schedules flush to disk like
fsync
To your other question we're still trying to come up with numbers, the system
has many things going on and showing something 100% attributable to this is
hard - I'm trying to see if we can get a more exact A/B test.
madvise() doesn't help ensure there's less dirty data in the system, which is
d
@n3npq as I called out a few times... the examples I found were all in the
build/ directory... maybe I'm just not seeing another good example.
Moving to mmap() and madvise() is a major invasive change... if someone wants
to take that on, awesome, but this is a simple solution that buys us a lot
@jayzmh - add a static variable to expand the macro as a "one shot" ... there
are many places in rpm that do that, hurts little (until rpm can capture global
configuration object).
Meanwhile I recommend the *_DONTNEED mmap implementation instead of fsync. RPM
used that for years, and *_DONTNEED
I've been looking at various things related to rpm signatures and their
handling, and multiple signatures happens to be one of them.
Your use-case is not just a matter of more signatures though, it'd require a
particular verification policy and a way to express that within rpm as well,
roughly:
Trivial fixes to silence compile warnings..
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/191
-- Commit Summary --
* fix comparison between signed and unsigned integer expressions
* fix implicit declarations of lua funct
