[LU-11221] Do not hold pages locked for network IO on the server.

• Type: Improvement
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.13.0, Lustre 2.12.4
• Assignee: Alex Zhuravlev
• Reporter: Oleg Drokin

Description

Investigating some customer issues I noticed that currently our read looks roughly like this:
1. obtain the pages and lock them
2. prepare and then execute our bulk request
3. unlock the pages.

essentially holding pages locked for network IO. This seems to be not super optimal since parallel reads cannot proceed and must wait for each other read to complete first. This would also help in case of client death/network problems since any hung bulk RPCs would not have as much impact on parallel operations.

We already have dlm locks to protect us so we probably should be fine to drop the locked pages at step2 and possibly even for writes as well (need to investigate eviction implications) - we were already operating in this mode in 18. and prior before read only cache on the server was implemented and each RPC had a private pool of pages not connected to any inode mappings.

Issue Links

• is duplicated by: LU-9232 Reduce osd-ldiskfs page lock hold time for read