[OpenAFS-devel] .35 sec rx delay bug?

[Tom Keiser]

On 11/6/06, Rainer Toebbicke <rtb@pclella.cern.ch> wrote:
> Derrick J Brashear wrote:
>
> >
> > Do you have a patch of what you have so far?
> >
>
> Help yourself, work in progress:
>
> /afs/cern.ch/user/r/rtb/public/rx_patch_LockAndClock
>
> (the patch is called ...AndClock since it also switches to using the
> itimer interface which is faster than gettimeofday()). But it's
> obvious how to revert that part if ever.
>
> For Tom Keiser:
>
> it's based on 1.4.1, adapted to 1.4.2.
>
> You're right, releasing and re-acquiring a mutex is exppensive,
> therefore I packed an additional drop_lock into the call struct which
> anybody can set, and which causes the lock to be dropped.
>
>
> Lockless however: you need the call->lock whatever you're doing. For a
> loooong time.
>

Ok.  Looking at your patch I see we're talking about two different rx
subsystems.  I was referring to the Rx packet _allocator_ being
lockless.  I see you're referring to a call->lock fairness problem
caused by a transmitter holding the lock for too long.  Well,
actually, that's not really true, either.  If you dig far enough down
into the stack, you'll see that we drop call->lock around the
rxi_SendPacketList()/rxi_SendPacket() call at the bottom of
rxi_SendList().  On SMPs this should be enough, but on uniprocessor
machines this probably isn't enough.  Actually, I think it could be
enough on a uniprocessor as well (under the following conditions):

* hot threads turned OFF
* Rx receive thread set to a higher priority
* preemptible kernel

Regards,

-- 
Tom Keiser
tkeiser@gmail.com