Re: NFS client latencies

Ingo Molnar
2005-03-31T07:00:34Z

* Trond Myklebust <trond.myklebust@fys.uio.no> wrote:

> > The 7 ms are spent in this loop:
>
> Which is basically confirming what the guys from Bull already told me,
> namely that the radix tree tag stuff is much less efficient that what
> we've got now. I never saw their patches, though, so I was curious to
> try it for myself.

i think the numbers are being misinterpreted. I believe this patch is a
big step forward. The big thing is that nfs_list_add_request() is O(1)
now - while _a single request addition to the sorted list_ triggered the
1+ msec latency in Lee's previous trace. I.e. the previous trace showed
a 1+ msec latency for a single page IO submission, while his new trace
shows _thousands_ of pages submitted for NFS IO - which is a very
different beast!

i think all it needs now is a lock-breaker in the main radix-lookup loop
in nfs_scan_lock_dirty(), or a latency-oriented reduction in the npages
argument, to make the loop bounded. The nfs_list_add_request() code
unbreakable from a latency POV. The patch looks really great to me,
kudos for pulling it off that fast.

(Also, i'd not declare this variant _slower_ based on latencies, unless
proven in real benchmarks. A faster implementation can easily have
higher latencies, if some detail changed - and lots of details changed
due to your patch. And i'd not even declare latency that much worse,
unless it's been measured with the tracer turned off. (Lee, could you
try such a comparison, worst-case latency with and without the patch,
with LATENCY_TRACE turned off in the .config but latency timing still
enabled?) The latency tracer itself can baloon the latency.)

Ingo