Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-16566

rq_sepol makes ptlrpc_request exceed 1024 bytes

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Fixed
    • Minor
    • Lustre 2.16.0
    • Lustre 2.16.0, Lustre 2.12.9, Lustre 2.15.2
    • 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.

      Attachments

        Issue Links

          Activity

            People

              eaujames Etienne Aujames
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: