Chuck Silvers <chuq%chuq.com@localhost> writes: > in the longer term, I think it would be good to use even larger pool pages > for large pool objects on systems that have relatively large amount of memory. > even with your patch, a 1k pool object on a system with a 4k VM page size > still has 33% overhead for the redzone, which is a lot for something that > is enabled by DIAGNOSTIC and is thus supposed to be "inexpensive". So maybe the real bug is that this check should not be part of DIAGNOSTIC. I remember from 2.8BSD that DIAGNOSTIC was basically just supposed to add cheap asserts and panic earlier but not really be slower in any way anybody would care about. It seems easy enough to make this separate and not get turned on for DIAGNOSTIC, but some other define. It might even be that for current the checked-in GENERIC enables this. But someone turning on DIAGNOSTIC on 9 shouldn't get things that hurt memory usage really at all, or more than say a 2% degradation in speed. > there's a tradeoff here in that using a pool page size that matches the > VM page size allows us to use the direct map, whereas with a larger > pool page size we can't use the direct map (at least effectively can't today), > but for pools that already use a pool page size that is larger than > the VM page size (eg. buf16k using a 64k pool page size) we already > aren't using the direct map, so there's no real penalty for increasing > the pool page size even further, as long as the larger pool page size > is still a tiny percentage of RAM and KVA. we can choose the pool page size > such that the overhead of the redzone is bounded by whatever percentage > we would like. this way we can use a redzone for most pools while > still keeping the overhead down to a reasonable level. That sounds like great progress and I don't mean to say anything negative about that.
Attachment:
signature.asc
Description: PGP signature