On 11/6/06, Rainer Toebbicke <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
