ACM Home Page
Please provide us with feedback. Feedback
Maximum benefit from a minimal HTM
Full text PdfPdf (457 KB)
Source
Architectural Support for Programming Languages and Operating Systems archive
Proceeding of the 14th international conference on Architectural support for programming languages and operating systems table of contents
Washington, DC, USA
SESSION: Transactional memories table of contents
Pages 145-156  
Year of Publication: 2009
ISBN:978-1-60558-406-5
Also published in ...
Authors
Owen S. Hofmann  University of Texas at Austin, Austin, TX, USA
Christopher J. Rossbach  University of Texas at Austin, Austin, TX, USA
Emmett Witchel  University of Texas at Austin, Austin, TX, USA
Sponsors
SIGPLAN: ACM Special Interest Group on Programming Languages
SIGOPS: ACM Special Interest Group on Operating Systems
ACM: Association for Computing Machinery
SIGARCH: ACM Special Interest Group on Computer Architecture
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 31,   Downloads (12 Months): 197,   Citation Count: 0
Additional Information:

abstract   references   index terms   collaborative colleagues  

Tools and Actions: Request Permissions Request Permissions    Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1508244.1508262
What is a DOI?

ABSTRACT

A minimal, bounded hardware transactional memory implementation significantly improves synchronization performance when used in an operating system kernel. We add HTM to Linux 2.4, a kernel with a simple, coarse-grained synchronization structure. The transactional Linux 2.4 kernel can improve performance of user programs by as much as 40% over the non-transactional 2.4 kernel. It closes 68% of the performance gap with the Linux 2.6 kernel, which has had significant engineering effort applied to improve scalability.

We then extend our minimal HTM to a fast, unbounded transactional memory with a novel technique for coordinating hardware transactions and software synchronization. Overflowed transactions run in software, with only a minimal coupling between hardware and software systems. There is no performance penalty for overflow rates of less than 1%. In one instance, at 16 processors and an overflow rate of 4%, performance degrades from an ideal 4.3x to 3.6x.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

1
 
2
C. Blundell, E. C. Lewis, andM.M. K.Martin. Deconstructing transactions: The subtleties of atomicity. In WDDD. 2005.
3
4
5
6
7
8
 
9
C. Click Jr. Pausing transactional memory hardware. In Cliff Click Jr.'s Blog's Blog, 2007. URL http://www.typepad.com/t/trackback/240313/20967813.
10
 
11
D. Dice, O. Shalev, and N. Shavit. Transactional locking II. In DISC. 2006.
 
12
D. Dice, M. Herlihy, D. Lea, Y. Lev, V. Luchangco, W. Mesard, M. Moir, K. Moore, and D. Nussbaum. Applications of the adaptive transactional memory test platform. In TRANSACT, 2008.
 
13
E. Elnozahy, D. Johnson, and Y. Wang. A survey of rollbackrecovery protocols in message-passing systems, 1996. URL citeseer.ist.psu.edu/article/elnozahy96survey.html.
 
14
15
 
16
J. R. Larus and R. Rajwar. Transactional Memory. Morgan & Claypool, 2006.
 
17
 
18
 
19
K. M. Mark Moir and D. Nussbaum. The adaptive transactional memory test platform: A tool for experimenting with transactional code for rock. In TRANS-ACT, February 2008.
20
 
21
C. C. Minh, J. Chung, C. Kozyrakis, and K. Olukotun. Stamp: Stanford transactional applications for multi-processing. In IISWC, 2008.
 
22
J. K. Ousterhout. Why aren't operating systems getting faster as fast as hardware? In USENIX Summer, pages 247--256, 1990.
 
23
24
25
 
26
H. Ramadan, C. Rossbach, and E. Witchel. The Linux kernel: A challenging workload for transactional memory. In WTW, 2006.
 
27
H. Ramadan, C. Rossbach, and E. Witchel. Dependence-aware transactional memory for increased concurrency. In MICRO, 2008.
28
29
30
 
31
32
33
 
34
M. F. Spear, M. M. Michael, and M. L. Scott. Inevitability mechanisms for software transactional memory. In TRANSACT, 2008.
 
35
M. M. Swift, H. Volos, N. Goyal, L. Yen, M. D. Hill, and D. A. Wood. OS support for virtualizing transactional memory. In TRANSACT, 2008.
 
36
 
37
C. Zilles and L. Baugh. Extending hardware transactional memory to support nonbusy waiting and nontransactional actions. In TRANSACT, 2006.

Collaborative Colleagues:
Owen S. Hofmann: colleagues
Christopher J. Rossbach: colleagues
Emmett Witchel: colleagues