Authors: Christopher J. Rossbach (UT Austin), Owen S. Hoffman (UT Austin), Donald E. Porter (UT Austin), Hany E. Ramadan (UT Austin), Aditya Bhandari (UT Austin), and Emmett Witchel (UT Austin)
Paper: http://www.sosp2007.org/papers/sosp056-rossbach.pdf
(SOSP 2007 presentation)
This paper presents an effort to use transactional memory in the Linux kernel. The main contribution seems to be the demand that transactions interoperate with locks for legacy code reasons. They have a "cxspinlock" API that allows this, which in turn allows you to do I/O with transactions. They note that priority inversion can still happen in a transactional system, but they propose a simple hardware extension to alleviate this (I didn't quite follow exactly what this was...see paper I guess).
Questions:
Q) Are there pathological cases you didn't talk about (he did talk about exponential backoff in transaction resolution being a problem)
A) overrunning the transactional memory (roughly) can be a problem; no good solution from community
Q) Is this how you would do things if we started over with transactions?
A) No, probably not. But this is the world we live in.
Q) Doesn't using a simulator goof your numbers? How do you calibrate?
A) mumble.
(there was another question I missed)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment