* get_lock_alloc_layout
@ 2010-07-01 13:50 Andy Adamson
2010-07-01 14:11 ` get_lock_alloc_layout Benny Halevy
0 siblings, 1 reply; 3+ messages in thread
From: Andy Adamson @ 2010-07-01 13:50 UTC (permalink / raw)
To: Benny Halevy; +Cc: linux-nfs@vger.kernel.org Mailing list
Hi Benny
Why do we have the complexity of waiting on a bit lock for allocating
a layout? Why can't we use the normal form:
take the i_lock
lookup layout
if (layout == NULL) {
give up i_lock
allocate and init new layout
return NULL if allocation fails
take the i_lock
lookup layout
if (layout == NULL)
set new layout for return
else
set found layout for return
}
give up i_lock
if new was allocated and not used
free the new layout
return layout
-->Andy
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: get_lock_alloc_layout
2010-07-01 13:50 get_lock_alloc_layout Andy Adamson
@ 2010-07-01 14:11 ` Benny Halevy
2010-07-01 14:19 ` get_lock_alloc_layout Andy Adamson
0 siblings, 1 reply; 3+ messages in thread
From: Benny Halevy @ 2010-07-01 14:11 UTC (permalink / raw)
To: Andy Adamson; +Cc: linux-nfs@vger.kernel.org Mailing list
On Jul. 01, 2010, 16:50 +0300, Andy Adamson <andros@netapp.com> wrote:
> Hi Benny
>
> Why do we have the complexity of waiting on a bit lock for allocating
> a layout? Why can't we use the normal form:
It's possible but the expectation was that the race here would
not be infrequent enough it's worth (statistically) losing it.
Benny
>
> take the i_lock
> lookup layout
> if (layout == NULL) {
> give up i_lock
> allocate and init new layout
> return NULL if allocation fails
> take the i_lock
> lookup layout
> if (layout == NULL)
> set new layout for return
> else
> set found layout for return
> }
> give up i_lock
> if new was allocated and not used
> free the new layout
> return layout
>
>
> -->Andy
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: get_lock_alloc_layout
2010-07-01 14:11 ` get_lock_alloc_layout Benny Halevy
@ 2010-07-01 14:19 ` Andy Adamson
0 siblings, 0 replies; 3+ messages in thread
From: Andy Adamson @ 2010-07-01 14:19 UTC (permalink / raw)
To: Benny Halevy; +Cc: linux-nfs@vger.kernel.org Mailing list
On Jul 1, 2010, at 10:11 AM, Benny Halevy wrote:
> On Jul. 01, 2010, 16:50 +0300, Andy Adamson <andros@netapp.com> wrote:
>> Hi Benny
>>
>> Why do we have the complexity of waiting on a bit lock for allocating
>> a layout? Why can't we use the normal form:
>
> It's possible but the expectation was that the race here would
> not be infrequent enough it's worth (statistically) losing it.
Well, I feel that for code maintainability that we use the normal
form. I'll submit a patch.
-->Andy
>
> Benny
>
>>
>> take the i_lock
>> lookup layout
>> if (layout == NULL) {
>> give up i_lock
>> allocate and init new layout
>> return NULL if allocation fails
>> take the i_lock
>> lookup layout
>> if (layout == NULL)
>> set new layout for return
>> else
>> set found layout for return
>> }
>> give up i_lock
>> if new was allocated and not used
>> free the new layout
>> return layout
>>
>>
>> -->Andy
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-
>> nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-07-01 14:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-01 13:50 get_lock_alloc_layout Andy Adamson
2010-07-01 14:11 ` get_lock_alloc_layout Benny Halevy
2010-07-01 14:19 ` get_lock_alloc_layout Andy Adamson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.