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

Strided lock proposal - Feature proposal for 2.8

Details

    • New Feature
    • Resolution: Won't Do
    • Minor
    • None
    • None
    • None
    • 3
    • 17170

    Description

      This ticket is a placeholder for further information forthcoming.

      Briefly, strided locking is a proposed new feature to make improved shared file IO performance possible in certain situations. This is being proposed at the Lustre developers meeting at LLNL (currently ongoing).

      Details will be forthcoming, for now, this ticket is mostly to allow me to push the prototype to Gerrit for ease of viewing.

      Attachments

        Issue Links

          Activity

            [LU-6148] Strided lock proposal - Feature proposal for 2.8

            This approach was abandoned in favour of lockahead.

            adilger Andreas Dilger added a comment - This approach was abandoned in favour of lockahead.

            Jinshan suggested implementing an ioctl for user space to request LDLM locks, allowing user space to 'lock ahead' of the actual IO, and we agreed I'd implement that and test it for performance before considering strided locks further. If that can get most of the performance of file per process, then there isn't much point to strided locks, and we do not need to add the complexity. We agreed there that if that doesn't close the gap, strided locks are worth considering.

            A prototype of lock ahead is here:
            LU-6179

            This ticket's going to be on hold until we have more results there.

            paf Patrick Farrell (Inactive) added a comment - Jinshan suggested implementing an ioctl for user space to request LDLM locks, allowing user space to 'lock ahead' of the actual IO, and we agreed I'd implement that and test it for performance before considering strided locks further. If that can get most of the performance of file per process, then there isn't much point to strided locks, and we do not need to add the complexity. We agreed there that if that doesn't close the gap, strided locks are worth considering. A prototype of lock ahead is here: LU-6179 This ticket's going to be on hold until we have more results there.

            Alex - The presentation PDF explains why not in a bit more detail, giving a few reasons.

            The main reason is what I'm calling write visibility:

            Client A and B both have the same group lock.
            Client A reads some pages, then client B writes to those pages.
            Client A reads the pages again, but because it has a lock on the file, it does not realize the pages have been modified & will re-use its cached pages.

            Some of the more complex data formats used in HPC - Such as HFD5 - write out in file metadata as part of writing out a file, and it requires write visibility in the course of the IO.

            paf Patrick Farrell (Inactive) added a comment - Alex - The presentation PDF explains why not in a bit more detail, giving a few reasons. The main reason is what I'm calling write visibility: Client A and B both have the same group lock. Client A reads some pages, then client B writes to those pages. Client A reads the pages again, but because it has a lock on the file, it does not realize the pages have been modified & will re-use its cached pages. Some of the more complex data formats used in HPC - Such as HFD5 - write out in file metadata as part of writing out a file, and it requires write visibility in the course of the IO.

            what about group locks?

            bzzz Alex Zhuravlev added a comment - what about group locks?

            Presentation slides from developer's conference.

            paf Patrick Farrell (Inactive) added a comment - Presentation slides from developer's conference.

            Prototype/proof of concept here:
            http://review.whamcloud.com/13498

            paf Patrick Farrell (Inactive) added a comment - Prototype/proof of concept here: http://review.whamcloud.com/13498

            Patrick Farrell (paf@cray.com) uploaded a new patch: http://review.whamcloud.com/13498
            Subject: LU-6148 ldlm: Strided locking prototype
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: 590c2b30d66021aac4f4a31fb05754036092c0dd

            gerrit Gerrit Updater added a comment - Patrick Farrell (paf@cray.com) uploaded a new patch: http://review.whamcloud.com/13498 Subject: LU-6148 ldlm: Strided locking prototype Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 590c2b30d66021aac4f4a31fb05754036092c0dd

            People

              wc-triage WC Triage
              paf Patrick Farrell (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: