NV-HTM

• allows PM transaction execution via existing HTM implementations
  • after committing modifications use the software to persist
  • postpone commit events until logging of data versions is ensured
  • pruning commit logs by using checkpointing schemes

Issues

• undo / redo logging assumes all transactional updates persist in the log before persistent data is modified
• commodity HTM requires that the transaction be committed before the cache log is flushed to memory

Basics

• non-durable commit: effects of commit are made visible but not necessarily persisted in PM
• durable commit: waits for the log and any dependent logs to reach the PM
• although data may not actually be committed, when recovering NV-HTM discards the data's state and replays the persisted logs
  • A program is notified of a commit and attempts to read an address of data involved in said commit. The data has not actually been written; only its logs have been persisted. We must read through the logs to provide the program with the correct values instead of reading from the address's actual memory. Does this present a performance issue? Would it be comparable to wait for the data to commit?

Challenges

ジュ＼ゲム・ジュ＼ゲム
ゴ＼コーノ・スリキレ
カイジャリス＼イギョノ
スイギョ＼マツ
ウンラ＼イマツ
フーラ＼イマツ
ク＼ーネルトコロ＼ニ・ス＼ムトコロ
ヤブラコ＼ージノ・ブラコ＼ージ
パ＼イポパ＼イポパ＼イポノ・シューリ＼ンガン
シューリ＼ンガンノ・グーリ＼ンダイ
グーリ＼ンダイノ・ポンポコピ＼ーノ・ポンポコナ＼ーノ
チョー・キュ＼ーメーノ・チョ＼ースケ

HTM-Compatible Asynchronous Logging

• uses decentralized logging; gives each thread a log
  • Can a transaction depend on transactions from other threads?
• non-durable log
  • only persisted after the non-durable commit event; marker is placed after durable commit event
  • What purpose does this log serve? So upon recovery it knows which addresses it was in the middle of changing?

Enforce Transaction Dependency

• are durable commits flushing at the same order non-durable commits are flushing
• NV-HTM must wait for a transaction to be non-durably committed before committing the log to PM.

Checkpointing

• Backward Filtering Checkpoint (BFC)
  • remove repeated writes / flushes to cache lines by different transactions
• relies on CoW to reduce spatial overhead

Assumptions

• HTM will retry transactions, requiring a global lock if necessary
• HTM exposes interface for begin / commit / abort events

Notes

• The persistent snapshot is copied from persistent memory to volatile memory (DRAM) as a working snapshot. NV-HTM modifies this working snapshot and yields: 1) a reduced write load; 2) faster write times (it hasn't necessarily persisted the write yet??)
• If thread A is about to commit a transaction that performed a write and thread B starts a read only transaction right before thread A starts waiting for a commit then thread A will have to wait for the read transaction to finish since the threads don't know before hand whether they are performing read-only procedures.
• Why does a transaction need to advertise (update its timestamp) when being committed?
• They require introducing a delay (sleep for an amount of time) between line 27 and line 28 for older CPUs and multi-socket machines.