On 2025/3/26 13:18, Eric Biggers wrote:
On Wed, Mar 26, 2025 at 09:30:51AM +0800, LongPing Wei wrote:
try_verify_in_tasklet
If verity hashes are in cache, verify data blocks in kernel tasklet
instead
- of workqueue. This option can reduce IO latency.
+ of workqueue. This option can reduce IO latency. The size limits could be
+ configured via /sys/module/dm_verity/parameters/use_bh_bytes. The four
+ parameters correspond to limits for IOPRIO_CLASS_NONE,IOPRIO_CLASS_RT,
+ IOPRIO_CLASS_BE and IOPRIO_CLASS_IDLE in turn.
+ For example:
+ <none>,<rt>,<be>,<idle>
+ 4096,4096,4096,4096
I'm concerned about adding yet another performance tuning UAPI, which will then
have to be maintained going forwards, even if the implementation changes. See
e.g. how try_verify_in_tasklet has ended up not actually using tasklets anymore.
Is there any strong reason for userspace needing to configure use_bh_bytes
differently on different systems, vs. just having the kernel choose the best
value automatically without any new UAPI surface?
Keep in mind that the tunables could also be added separately later.
- Eric
Hi, Eric
It seems that it is not easy to implement the idea that having the
kernel choose the best value automatically.
Unlike on Linux servers and PCs, the CPU load,number and frequency on
Android devices may vary. For Android devices, dynamic policies may have
a more general benefit effect.
On the low-end device I tested locally, soft interrupts would be
concentrated on CPU4~7. I tried to increase use_bh_bytes but got
negative effects. The time cost of a single block softirq becomes
higher, which will defer subsequent block softirq.
But on the devices with UFS MCQ or NVME SSD, most verity_end_io should
be called in hardirq context directly but not softirq. These devices
have the potential to raise the threshold.
- LongPing
