[LU-12550] automatic lockahead Created: 15/Jul/19 Updated: 01/Sep/23 |
|
| Status: | Open |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Patrick Farrell (Inactive) | Assignee: | Patrick Farrell |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||||||||||||||
| Description |
|
This is something Li Xi suggested a few years ago - It should be possible to do lockahead automatically by tracking the write pattern (like LU-12468) and using server-side contention checking to tell the client when to do this. (Lockahead is currently only usable by clients which know to ask for it.) This should let clients get good performance when strided writes with non-stripe aligned i/o, as long as the i/o is page aligned (LDLM & OSC locks are at page granularity). |
| Comments |
| Comment by Patrick Farrell (Inactive) [ 15/Jul/19 ] |
|
This is just a side project right now, but I have a quick prototype, and wanted to get it in git. |
| Comment by Gerrit Updater [ 15/Jul/19 ] |
|
|
| Comment by Andreas Dilger [ 22/Sep/20 ] |
|
Instead of doing lockahead for small unaligned writes, I think it is probably better to just do lockless "direct" writes to the OST. That avoids the overhead of the LDLM_ENQUEUE RPC to lockahead the lock, when we still need to do the write from the client. Even if the lockahead was expanded to cover whole pages (risking some lock contention on the hopes that sparse random writers will have few conflicts), unaligned writes would have to do read-modify-write of the partial pages. That means at least 3 RPCs (LDLM_ENQUEUE for lockahead, OST_READ of the start/end page(s), and the OST_WRITE), but up to 6 (if separate OST_READ RPCs are sent for the start/end pages, LDLM_BL_CALLBACK if there is a conflict for the expanded lock region, and LDLM_CANCEL if the lock can't be cancelled with ELC on the OST_WRITE). Conversely, lockless writes would only be one OST_WRITE RPC, and may even avoid the RDMA round-trip if it is a short write that fits into the RPC request (though that is not different than the OST_WRITE for the locked write). |
| Comment by Patrick Farrell [ 09/Jul/21 ] |
|
As Andreas said above, the scope for automatic lockahead is pretty limited and I have no intention of reviving this work. However, the contention detection patch here: Can be extracted from the writeahead tracking & automatic lockahead patches and used for switching from buffered i/o (which cannot be lockless) to direct i/o (which can be lockless). |