[LU-13407] Deprecate lu_env for minimizing stack use, and reduce usage over-all Created: 02/Apr/20 Updated: 02/Apr/20 |
|
| Status: | Open |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor |
| Reporter: | Neil Brown | Assignee: | WC Triage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Rank (Obsolete): | 9223372036854775807 |
| Description |
|
lu_env clutters the code - making it had to read - for reasons that are not obvious and so hard to review. The documented justification (clio.txt section 8) is two-fold 1/ To avoid a large stack, modules can request (vi le_ctx) large variables that would otherwise be on-stack, to be stored in the lu_env. This was likely important when 4K stacks were a (potential) reality in Linux, but that disappeared nearly 10 years ago (dcfa7262801). Stacks on all supported kernels are 8k or more and kernels since 4.9 have virtually mapped stacks which are much bigger. 2/ (le_ses) Lustre has multiple threads and lu_env (via le_ses) has been used to store thread context. Even outside of kernel threads, lu_env/le_ses is also used to store context for an individual RPC. This is a valid need, but can probably be expressed more clearly without (some of) the complexity of lu_env. The proposal is to identify all uses of le_ctx for saving stack space, to convert them to use on-stack variables, and to remove le_ctx completely. Secondly, uses of le_ses can be catalogued and opportunities for simplification sought and put into effect.
|