[Lustre-devel] [RFC] parallel enqueue

[Lustre-devel] [RFC] parallel enqueue

[Alex Zhuravlev]

Hi,

in some cases (truncate, append) we still use serialized enqueue
when all locks have to be enqueued synchronously one by one.

what if we could mark all locks issued by single client with some
unique tag (timestamp + nid?), then enqueue them all and then, in
case of conflict, in blocking ast handler compare tag of conflicting
lock with own tag, cancel our granted locks if our tag is greater
than tag of conflicting lock and enqueue them again?

thanks, Alex

[Lustre-devel] [RFC] parallel enqueue

[Peter J Braam]

Yes this is a good idea, but probably not extremely urgent.

- Peter -

Alex Zhuravlev wrote:
> Hi,
>
> in some cases (truncate, append) we still use serialized enqueue
> when all locks have to be enqueued synchronously one by one.
>
> what if we could mark all locks issued by single client with some
> unique tag (timestamp + nid?), then enqueue them all and then, in
> case of conflict, in blocking ast handler compare tag of conflicting
> lock with own tag, cancel our granted locks if our tag is greater
> than tag of conflicting lock and enqueue them again?
>
> thanks, Alex
>
>
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
>   

[Lustre-devel] [RFC] parallel enqueue

[Eric Barton]

This sounds great!

But are there any livelock issues? 

> -----Original Message-----
> From: lustre-devel-bounces at lists.lustre.org 
> [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of 
> Alex Zhuravlev
> Sent: 08 February 2008 3:32 PM
> To: lustre-devel at lists.lustre.org
> Subject: [Lustre-devel] [RFC] parallel enqueue
> 
> Hi,
> 
> in some cases (truncate, append) we still use serialized enqueue
> when all locks have to be enqueued synchronously one by one.
> 
> what if we could mark all locks issued by single client with some
> unique tag (timestamp + nid?), then enqueue them all and then, in
> case of conflict, in blocking ast handler compare tag of conflicting
> lock with own tag, cancel our granted locks if our tag is greater
> than tag of conflicting lock and enqueue them again?
> 
> thanks, Alex
> 
> 
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
> 

[Lustre-devel] [RFC] parallel enqueue

[Alex Zhuravlev]

well, the idea is to fallback to serialized enqueue once such
collision is detected: this allow to avoid livelock problem
and rpc storms.


thanks, Alex

Eric Barton wrote:
> This sounds great!
> 
> But are there any livelock issues? 
> 
>> -----Original Message-----
>> From: lustre-devel-bounces at lists.lustre.org 
>> [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of 
>> Alex Zhuravlev
>> Sent: 08 February 2008 3:32 PM
>> To: lustre-devel at lists.lustre.org
>> Subject: [Lustre-devel] [RFC] parallel enqueue
>>
>> Hi,
>>
>> in some cases (truncate, append) we still use serialized enqueue
>> when all locks have to be enqueued synchronously one by one.
>>
>> what if we could mark all locks issued by single client with some
>> unique tag (timestamp + nid?), then enqueue them all and then, in
>> case of conflict, in blocking ast handler compare tag of conflicting
>> lock with own tag, cancel our granted locks if our tag is greater
>> than tag of conflicting lock and enqueue them again?
>>
>> thanks, Alex
>>
>>
>> _______________________________________________
>> Lustre-devel mailing list
>> Lustre-devel at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>>
> 
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel