Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-1683

Move write_lsn advancement out of log_release

      Various tests show that the controlled advancement of write_lsn in __log_release results in a lot of time wasted in yield or cond_wait and scheduling issues. With the default of running logging in-memory, application threads should not have to wait for the LSN to advance to continue.

      My initial thoughts for this are to have a worker thread that scans through the slot pool looking for slots that can advance write_lsn and are done writing. We would add a new state that would be set on the slot in log_release and the worker thread would see it and could advance write_lsn.

      Various things to think about:

      • Threads that need to sync anyway must still wait for the LSN to advance so the existing code likely remains in a conditional code path.
      • The thread calling log_release frees the slot when done. We'll need a new flag, or return value or something to only do that conditionally when the log_release thread does not hand off the slot. Otherwise the worker thread will free the slot when it does its work.
      • Consideration for the worker thread back-off yield mechanism to be somewhat sophisticated. It is important that the write_lsn be advanced in a timely manner, but we don't want to spin when there are not many writes.
      • Need a new slot state that will indicate to the worker thread this slot should be processed by it.
      • Careful consideration for all the various log sync settings and making sure threads are properly waiting (or not) for all the different settings.

            Assignee:
            sue.loverso@mongodb.com Susan LoVerso
            Reporter:
            sue.loverso@mongodb.com Susan LoVerso
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: