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
