Chris Sarcone writes:
Drew --
When using a filter interrupt with Tiger, I see a roughly 20%
latency
reduction (10us -> 8us) and with Panther, I see a nearly 40%
reduction
(17.1us -> 9.9us). This is atop a hardware overhead of roughly
3.5us,
which is constant regardless of platform.
It is interesting to note that Tiger is *MUCH* faster at either
scheduling interrupt threads, or at scheduling threads in general
than
Panther is. Kudos to whomever was responsible for this
improvement.
Yes it is quite a bit faster! Kernel engineers modified the scheduler
bits to be much faster, added primitives to make IOWorkLoop threads
faster (thread_block_parameter() instead of thread_get_cont_arg()/
thread_set_cont_arg()) and also modified the
IOSharedInterruptController code to have better performance (all of
which directly impacted those latency measurements).
Very nice work.
FWIW, when I was implementing my filter interrupt, I looked
at this code, and it left me dazed and confused ;). Can you
explain something?
In IOWorkLoop::threadMain(), it blocks with thread_block_parameter
((thread_continue_t)threadMainContinuation, this);
Does that mean that when it wakes up, it start from
IOWorkLoop::threadMainContinuation, which re-enters
threadMain()? What's the advantage to doing it this way?
Our IOPS numbers increased quite a bit on FibreChannel disk arrays
due to the above changes, the removal of the kernel funnels, and some
other optimizations on the I/O path (including removing some DART
setup cost, not allocating sense data descriptors on transports that
provide auto-sense data, etc.).
Yes, the DART setup was another major improvement that I noticed.
It decreases our large message latency dramatically between Panther
and Tiger. Eg, 2801us -> 2311us for a 1MB transfer.
Any chance of improving your IP stack latency? I see roughly 45us
1/2 RTT latency using the netperf UDP_RR pingpong tests between 2 dual
2.0GHz G5s running ethernet emulation on top of the Myrinet device I
keep talking about. This compares to 10.9us on a pair of 1.8GHz
dual opeteron 244s running linux with the same NIC. This is just
a one-byte UDP packet ping-ponging, so there should be no chance
of lock contention, etc.
Then again, don't improve it. Bad IP latency is one of the things
paying my check ;)
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-drivers/email@hidden
This email sent to email@hidden
