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
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 >
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 >
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