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

Create pid-based hash to enhance Jobstats performance

Details

    • Improvement
    • Resolution: Fixed
    • Minor
    • Lustre 2.11.0
    • Lustre 2.9.0
    • None
    • 9223372036854775807

    Description

      Currently jobstats gets information by either dedicating an entire node to a single job (LU-7195) or reading from the userspace environment for each call. The first is very fast, but can be inaccurate, the second introduces a significant performance penalty on the client. This patch creates a cache of JobID names mapped to PIDs. It has several fallback mechanisms in order to present the most accurate info available.

      Attachments

        Issue Links

          is related to

          Improvement - An improvement or enhancement to an existing feature or task. LUDOC-381 Improve documentation for jobstats

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open
          links to

          Web Link https://review.whamcloud.com/#/c/25208/

          Activity

            [LU-9221] Create pid-based hash to enhance Jobstats performance
            pjones Peter Jones added a comment -

            Landed for 2.11

            pjones Peter Jones added a comment - Landed for 2.11
            gerrit Gerrit Updater added a comment -

            Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/25208/
            Subject: LU-9221 jobstats: Create a pid-based hash for jobid values
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: 08479b74ec3599ee91e14f3f646389bb0aca4575

            gerrit Gerrit Updater added a comment - Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/25208/ Subject: LU-9221 jobstats: Create a pid-based hash for jobid values Project: fs/lustre-release Branch: master Current Patch Set: Commit: 08479b74ec3599ee91e14f3f646389bb0aca4575
            panda Andrew Perepechko added a comment -

            Another interesting tool which might be useful to implement this feature is the linux key management system (see man keyctl).

            One can create a key with some data attached and link it to one of the available keyrings (thread, process, session, default session, etc). The key will be stored on a temporal or permanent basis. The cache can be easily searched from the kernel using request_key().

            It's also possible to create a key type so that requested keys are created using a userspace upcall (see /sbin/request-key, /etc/request-key.conf).

            panda Andrew Perepechko added a comment - Another interesting tool which might be useful to implement this feature is the linux key management system (see man keyctl). One can create a key with some data attached and link it to one of the available keyrings (thread, process, session, default session, etc). The key will be stored on a temporal or permanent basis. The cache can be easily searched from the kernel using request_key(). It's also possible to create a key type so that requested keys are created using a userspace upcall (see /sbin/request-key, /etc/request-key.conf).
            bevans Ben Evans (Inactive) added a comment -

            https://jira.hpdd.intel.com/browse/LUDOC-381

            bevans Ben Evans (Inactive) added a comment - https://jira.hpdd.intel.com/browse/LUDOC-381
            bevans Ben Evans (Inactive) added a comment -

            JobID Cache Proposal.docx
            Updated doc

            bevans Ben Evans (Inactive) added a comment - JobID Cache Proposal.docx Updated doc
            hdoreau Henri Doreau (Inactive) added a comment -

            @cory: I'd be glad to help but it will not have much time to review Ben's patch before LUG...

            As seen in first revisions of the patch, introducing such a new cache comes with a risk of subtle race conditions and memory leaks. Therefore reviewing and testing it seriously cannot be done in a rush.

            hdoreau Henri Doreau (Inactive) added a comment - @cory: I'd be glad to help but it will not have much time to review Ben's patch before LUG... As seen in first revisions of the patch, introducing such a new cache comes with a risk of subtle race conditions and memory leaks. Therefore reviewing and testing it seriously cannot be done in a rush.
            pjones Peter Jones added a comment -

            Could still make 2.10 if reviews complete in time but otherwise will be in 2.10.1

            pjones Peter Jones added a comment - Could still make 2.10 if reviews complete in time but otherwise will be in 2.10.1
            spitzcor Cory Spitz added a comment -

            @hdoreau, the OpenSFS LWG is looking to you to be the reviewer of record for this enhancement. Can you accept? We're getting close to code cut-off for v2.10 and we were hoping that you would have time for reviews. Thanks!

            spitzcor Cory Spitz added a comment - @hdoreau, the OpenSFS LWG is looking to you to be the reviewer of record for this enhancement. Can you accept? We're getting close to code cut-off for v2.10 and we were hoping that you would have time for reviews. Thanks!
            spitzcor Cory Spitz added a comment -

            Patch up for review is at https://review.whamcloud.com/#/c/25208/.

            spitzcor Cory Spitz added a comment - Patch up for review is at https://review.whamcloud.com/#/c/25208/ .

            People

              bevans Ben Evans (Inactive)
              bevans Ben Evans (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: