G'day,
The attached patch makes the NLM client do exponential backoff
for the polling used to handle the case that the server has not
sent a GRANTED callback.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
On Tue, 26 Oct 2004, Greg Banks wrote:
> G'day,
>
> The attached patch makes the NLM client do exponential backoff
> for the polling used to handle the case that the server has not
> sent a GRANTED callback.
>
> Greg.
> --
> Greg Banks, R&D Software Engineer, SGI Australian Software Group.
> I don't speak for SGI.
i implemented something exactly like this in userland for some code for which
many ( > 30) hosts are competing for a lock. i didn't want to use blocking
locks as the performance was terrible (seeing one host obtain the lock
thousands of time in a row). instead i used non-blocking locks with the
following algorithim for backing off:
- client becomes more and more patient (similar to your exponential backoff
- mine is linear though)
- client eventually becomes impatient again
if i read your code right it looks like, once max delay is reached, it stays
there. this will mean that a client waiting a long time has an increasingly
significant change of being starved when a lock is under heavy contention
doesn't it? in any case it seems like resetting the delay to min after
reaching max (becoming impatient again) may give better performance on average
than simply staying at max.
kind regards.
-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself. --Shunryu Suzuki
===============================================================================
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Nov 08, 2004 at 10:27:19AM -0700, Ara.T.Howard wrote:
> On Tue, 26 Oct 2004, Greg Banks wrote:
> if i read your code right it looks like, once max delay is reached, it stays
> there.
Yes.
> this will mean that a client waiting a long time has an increasingly
> significant change of being starved when a lock is under heavy contention
> doesn't it?
Not if the server has queued the lock request. But then if the server
were correctly implemented it would probably be sending us a GRANTED
callback and we wouldn't need to poll.
> in any case it seems like resetting the delay to min after
> reaching max (becoming impatient again) may give better performance on
> average
> than simply staying at max.
Could do. Do you want to do the patch?
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tue, 9 Nov 2004, Greg Banks wrote:
>> this will mean that a client waiting a long time has an increasingly
>> significant change of being starved when a lock is under heavy contention
>> doesn't it?
>
> Not if the server has queued the lock request. But then if the server were
> correctly implemented it would probably be sending us a GRANTED callback and
> we wouldn't need to poll.
i figured as much - wan't quite sure the reason for the poll...
>> in any case it seems like resetting the delay to min after reaching max
>> (becoming impatient again) may give better performance on average than
>> simply staying at max.
>
> Could do. Do you want to do the patch?
i could - but not for a week or more... all i was really thinking is
delay =
delay < NLM_LOCK_RETRY_DELAY_MAX ? delay << 1 : NLM_LOCK_RETRY_DELAY_MIN;
cheers.
-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself. --Shunryu Suzuki
===============================================================================
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tue, Nov 09, 2004 at 09:54:11AM +1100, Greg Banks wrote:
> Not if the server has queued the lock request. But then if the server
> were correctly implemented it would probably be sending us a GRANTED
> callback and we wouldn't need to poll.
The Linux lockd should send a GRANTED message. The only reason I
implemented polling was as a workaround against broken lockd's that would
never send GRANTED messages if you used the (synchronous) NLM_LOCK call
instead of the (asynchronous) NLM_LOCK_MSG. HPUX 10.something was one
of them.
I agree though that the polling code is bad because it masks potential
bugs in the Linux lockd.
Olaf
--
Olaf Kirch | Things that make Monday morning interesting, #1:
[email protected] | "I want to use NFS over AX25, can you help me?"
---------------+
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs