Supplementing Maxime's answer: ## Goals/Optimization/cpu time/memory usage
Maxime covered more generically some of the ideas/work to address this. I will get a little more specific. We can split there into stuff that is already a wip, and future work. The current wip is expected to land early in the 26.04 cycle, it just wasn't ready by FF for this cycle. For wip performance we have - rewrite of expr tree factoring. This will be most relevant for individual profiles that already take a fairly long time to compile. It should help reduce the pathelogical node expansion cases, that result in significantly more nodes than final states. Its not yet to where I can give you concrete figures, but should be by release. - diff-encoding. Provides up to about 50% performance improvement, but can also cause 2x slowdown. We are tinker with heuristics to auto tune when it is applied. - user space zstd compression. This technically slows down the compile, but speeds up the load. But these are usually seen together as a single operation. In the compile and load case we see a small performance improvement when using similar compression levels as the kernel currently uses. However this gives us the ability to tune for performance (lower compression levels), or size (higher compression levels). Reloads of policy is always faster as it removes the compression phase from policy load. Note: this compressed policy is used for criu support, we compress it to reduce kernel memory impact. - front end driver rework to allow better sharing of between parses. I don't have a figure for this one yet, but it should be fairly significant for large policy sets like apparmor.d, as abstractions will get read once instead of thousands of times. - jobs reuse (depends on front end driver rework). Will Reduce forks to a fixed amount (default nproc), instead of 1 per file (so apparmor.d ~1600). Size/Memory use - diff-encoding. Currently giving an average of about ~30% size reduction on the apparmor.d profile set. - zstd compression. Tuning this to the higher ends we are seeing ~33% improvement in the criu policy size. Mid term: We have several improvements that are questionable as to whether they can be landed for 25.04. - shared resources between profiles. Kernel side a lot of support for this has already landed. There is a little more to do here, and work in the compiler. Technically it will incure a small increase in mediation time. As each shared resource must be consulted, instead of doing a single lookout. So its a balancing act between policy size, policy compile time and run time cost. - precompiled headers/abstractions (self explanatory) - triggers for kernel install to launch a policy pre-compile in background. The install it self doesn't need to block on the policy compile as worst case is the cache isn't fully compiled and it is then done at boot. - splitting policy up to reduce the presence of extra profiles. Longer term: There are a lot of improvements, and tuning. I could provide a list but it is likely to change some etc, and non of it will land before 26.04. Why not ship the profiles with each src package in ubuntu? Have the pros and cons been discussed somewhere?: yes. Generally speaking it comes to package maintenance, profile maintenance and syncing. Ideally profiles for a given src would be shipped with source, and also the profile is tracked and updated upstream to be able to get improvements from other distros etc. It then comes down to keeping the package and upstream in sync. Alex Murray wrote a doc around this, I will dig it out. There is certainly work to do around embedding profiles in src packages. There is also work to be done in splitting the profiles that don't get embedded into smaller more target sets, eg. server, desktop, ... instead of the current all in one. The all in one can then become a meta package for those who want an easy way to do that. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2121409 Title: [FFE] add a new apparmor.d package containing several apparmor profiles To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2121409/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
