From: "Eric Barton" <[EMAIL PROTECTED]>
Date: Mon, 11 Dec 2006 15:07:16 -0000
> From: Scott Atchley <[EMAIL PROTECTED]>
> Date: Mon, 11 Dec 2006 07:21:38 -0500
>
>
> Two other comments:
>
> 1) Do not hold any locks when calling any lnet_ functions.
Indeed. And I forgot to mention that you have to be in thread context too!
Yes, I'd already figured that one out. I'm really doing very little in
interrupt context, I foisted all that off on the service thread.
> Yikes. Yes. I'm pretty sure I wasn't, but good to keep in mind.
>
> Does that really mean no locks at all, or no locks that could turn into
> recursive lock attempts due to lnet calling back in? Are the lnet things
> (which get called into by lnd) all non-blocking?
LNET will not block when you call lnet_finalize() unless it is to allocate
memory. But it can call you back (e.g. to send an ACK when you finalize a
PUT).
Sure, leading to the obvious class of deadlocks. I just wondered whether
there was something I hadn't thought of which might be causing lnet to block.
All in all, it's best not to be holding any locks at all.
Of course. I don't actually believe there's any reason for me to be holding
any locks at that time. I'm trying to make sure everything is reentrant all
over the place, because that's the only way it's going to run at speed on a
6-cpu smp.
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
