d4f46a775d
Previous throttling implementation approached problem from the wrong side. It significantly limited useful delaying of TRIM requests and aggregation potential, while not so much controlled TRIM burstiness under heavy load. With this change random 4K write benchmarks (probably the worst case for TRIM) show me IOPS increase by 20%, average latency reduction by 30%, peak TRIM bursts reduction by 3 times and same peak TRIM map size (memory usage). Also the new logic does not force map size down so heavily, really allowing to keep deleted data for 32 TXG or 30 seconds under moderate load. It was practically impossible with old throttling logic, which pushed map down to only 64 segments. Reviewed by: smh MFC after: 2 weeks Sponsored by: iXsystems, Inc. |
||
---|---|---|
.. | ||
boot/zfs | ||
compat/opensolaris | ||
contrib/opensolaris | ||
dev |