A big issue in the kernel are asymmetries between review resource and patch submission.
If you have 20 inexperienced kernel engineers all doing big difficult work and submitting large series that need TONS of review (and sometimes essentially development-via-review) and only a few reviewers, you have a problem.
What compounds this is that not all review is equal.
It seems most people will only really look at the surface, and rather happily give tags.
I think that technical skill is not enough for review [as I have said very often - soft skills are the actually core ones] - you have to be willing to say no, you have to be willing to consider the wider picture.
Finding people who have the right skills, are willing to handle the stress + thanklessness, & who have the time is not easy.
So the asymmetry I think is insoluble.
It'd be good if we could have stricter controls to throttle incoming series though.
Prototype for type-based partitioning of Linux kernel slab caches: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434/24?u=melver
Compiler seems to be doing a good-enough job of inferring allocated types per /proc/slabinfo. With the diagnostic -Rpass=alloc-token I can see about 965 allocation sites where it failed to infer the allocated type, but most of them are "bag of bytes", and only few with complex sizeof calculations like struct_size that are too opaque right now (but can be fixed).