[LU-16566] rq_sepol makes ptlrpc_request exceed 1024 bytes Created: 17/Feb/23 Updated: 04/Feb/24 Resolved: 04/Feb/24 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.16.0, Lustre 2.12.9, Lustre 2.15.2 |
| Fix Version/s: | Lustre 2.16.0 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Andreas Dilger | Assignee: | Etienne Aujames |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | SELinux, lug23dd | ||
| Issue Links: |
|
||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
The rq_sepol field in struct ptlrpc_request makes the total structure size exceed 1024 bytes (slabinfo shows ptlrpc_cache is 1152 bytes in my system). Since this field is 327 bytes and is relatively rarely used, it would be possible to allocate the string from a separate slab on systems that have this feature enabled, point at a preallocated/preformatted refcounted/RCU policy string (i.e. ptlrpc_sec->ps_sepol?) instead of copying it into each ptlrpc_request (if the policies rarely change), or otherwise avoid allocating it when this feature is unused.
#define SELINUX_MODE_LEN 1
#define SELINUX_POLICY_VER_LEN 3 /* 3 chars to leave room for the future */
#define SELINUX_POLICY_HASH_LEN 64
#define LUSTRE_NODEMAP_SEPOL_LENGTH (SELINUX_MODE_LEN + NAME_MAX + \
SELINUX_POLICY_VER_LEN + \
SELINUX_POLICY_HASH_LEN + 3)
This memory reduction is particularly useful on the server where it needs to store many thousands of incoming RPC requests, and this field is never used. Unfortunately, just adding it to struct ptlrpc_cli_req will not reduce the space usage, since that is already the larger of the two structs in the union, but it wouldn't be terrible to move the rq_sepol pointer into ptlrpc_cli_req so that it is more clear this is only used on the client. |
| Comments |
| Comment by Andreas Dilger [ 17/Feb/23 ] |
|
I was wondering if there was a race between updating rq_sepol and/or ps_sepol via the upcall vs. copying the policy into the RPC, but I think that is a non-issue so long as the policy itself is not half updated when it is copied into the RPC. In the vast majority of cases, the policy will not be changing, and in very rare cases when it does, it isn't clear if it would be worse to send the new client policy to the MDS than the old one? The policy update is itself lazy and racy vs. the RPC creation so I don't think it makes a difference either way. |
| Comment by Gerrit Updater [ 26/Oct/23 ] |
|
"Etienne AUJAMES <eaujames@ddn.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/52845 |
| Comment by Gerrit Updater [ 04/Feb/24 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/52845/ |
| Comment by Peter Jones [ 04/Feb/24 ] |
|
Merged for 2.16 |