On 09/06, Tom Talpey wrote:
In addition to polluting fewer registers and generally being more
lightweight to frob just four low bits.
I am a bit shocked at the improvement though. It's almost worth a
fully profiled before/after analysis.
Reviewed-by: Tom Talpey <tom@xxxxxxxxxx>
Thanks, Tom. (see below)
Afraid this was a useless micro-optimization, I ran some tests with a
very light workload, and I observed a ~50% perf improvement already:
Record all cifs.ko functions:
# trace-cmd record --module cifs -p function_graph
(test-dir has ~50MB with ~4000 files)
Test commands after share is mounted and with no activity:
# cp -r test-dir /mnt/test
# sync
# umount /mnt/test
Number of traced functions:
# trace-cmd report -l | awk '{ print $6 }' | grep "^[0-9].*" | wc -l
- unpatched: 307746
- patched: 313199
Measuring the average latency of all traced functions:
# trace-cmd report -l | awk '{ print $6 }' | grep "^[0-9].*" |
jq -s add/length
- unpatched: 27105.577791262822 us
- patched: 14548.665733635338 us
So even though the patched version made 5k+ more function calls (for
whatever reason), it still did it with ~50% reduced latency.
On a larger scale, given the affected code paths, this patch should
show a relevant improvement.
So I ran these tests several times to confirm what I was seeing. Again,
they might look (and actually are) micro-optimizations at first sight.
But the improvement comes from the fact that cifs.ko calls the affected
functions many, many times, even for such light (50MB copy) workloads.
On those tests of mine, the user-perceived (i.e. wall clock) improvement
was presented as a 0.02 - 0.05 seconds difference -- still looks minor
for, e.g. NAS boxes that does backups once a week, but aiming for 24/7
90% loaded datacenter systems, my expectation is this will be called an
improvement.
Cheers,
Enzo
