Exploiting Off-the-Shelf Virtual Memory Mechanisms to Boost Software Transactional Memory

technologyfrom seed

Exploiting Off-the-Shelf Virtual Memory Mechanisms to Boost Software Transactional Memory

Amin Mohtasham, Paulo Ferreira and João Barreto

Exploiting Off-the-Shelf Virtual Memory Mechanisms to Boost Software Transactional Memory Amin Mohtasham

Email: [email protected]

technologyfrom seed

Multicore revolution

• Chip-multiprocessors are mainstream hardware

• We must effectively program these systems

Exploiting Off-the-Shelf Virtual Memory Mechanisms to Boost Software Transactional Memory January 22nd, 2014

technologyfrom seed

Lock-based methods

Parallel Programming with traditional locks is difficult

There is a trade-off between complexity and performance

Exploiting Off-the-Shelf Virtual Memory Mechanisms to Boost Software Transactional Memory January 22nd, 2014

technologyfrom seed

Software Transactional Memory


• Software Transactional Memory is:– Easy to use

– Portable

– Not limited by hardware capacity

technologyfrom seed

The dark side of STM

STM has more sequential overhead than HTM

How can we alleviate this overhead?


technologyfrom seed

A typical STM read operation

Amin MohtashamExploiting Off-the-Shelf Virtual Memory Mechanisms to Boost Software Transactional Memory

Physical Memory

Thread#1

X=10

readTx(X)

read(X)

if isConsistent() then

here comes the overhead

technologyfrom seed

Our objective

• Most transactional workloads are Read-Dominated

• Most of the read operations are consistent– Validation is a waste of work for consistent reads


Can we actually read directly from memory and avoid the validation?

technologyfrom seed

A naïve approach: Direct read operations


Physical Memory

Thread#1

X=10

read(X)

Thread#2

write(X)

read(X)

TX1

TX2

TX3

Is there any safe way to read directly from memory?

Inconsistent X=99

technologyfrom seed

An interrupt by hardware!


Process

Virtual Memory

• MMU is a common component of commodity hardware

• By relying on the page-level mechanisms in MMU, we can prevent threads from accessing a memory page

Amin Mohtasham

technologyfrom seed

A more sophisticated approach:Using page protection bits

Page TablePhysical Memory


PageBaseAddress Read Write

0x2FF8000 1 1

Thread#2Thread#1

write(X)

read(X)

TX1

TX2

0 0

read(X)

blockedblocked

0x2FF8000 X=10X=99

For a given page, how can we give different permissions to different threads?

technologyfrom seed

Mapped memory

• By using memory map functions, we can define different virtual memory regions with different protection levels


Page TablePhysical Memory

PageBaseAddress Read Write

0x2FF8000

0x2FF8000

0x2FF8000

0 0

1 1

Thread#1 Thread#2

read(X)

read(X)

X=10

[Abadi et al., ACM PPOPP’09]

technologyfrom seed

Proof of concept: PGSTM

• At most, one writer transaction at each time– Using a single global lock

• Multiple read-only transactions can at each time

• Read-only transactions can execute in parallel, as long as they do not read from pages being written


technologyfrom seed

PGSTM’s Memory Model


Page Table Physical Memory

Shared Data

Read-only region

Read/Write region

• Two different virtual memory regions pointed at same physical memory pages

• Read-only Region contains either read-only or inaccessible pages• In Read/Write region all pages are accessible and updatable

technologyfrom seed

PGSTM in action


Page TablePhysical Memory PageBaseAddress Read Write

0x2FF8000 1 1

0x2FF8000 X=10

Thread#2Thread#1

write(X)

read(X)

TX1

TX2

read(X)

0x2FF8000 1 1

0 0

blockedX=99

technologyfrom seed

When to unlock a page?

• Can we unlock the page when the writer commits?– It is not safe if there are other active read-only

transactions running

• Unlock only after such active transactions complete


technologyfrom seed

Evaluation environment

• List look-up benchmark

• Read-only transactions search for a random element

• Read/Write transactions modify a random element

• We compare our results with TML [Dalessandro et al.,Europar’10]


technologyfrom seed

TML: Transactional Mutex Locks

• At most, one writer transaction at each time– Using a single global lock

• Read-only transactions can not run in parallel with the writer transaction

• With the lowest sequential overhead


technologyfrom seed

Evaluation: Different contentions


Throughput for different contention levels[64 threads, 10% write-load]

Amin Mohtasham

Less contention

technologyfrom seed

Evaluation: Scalability


Throughput for different number of concurrent threads[2MB List, 10% write-load]

Amin Mohtasham

technologyfrom seed

Evaluation: Different write loads


Throughput for different write loads [2MB List, 64 threads]

Amin Mohtasham

technologyfrom seed

Conclusion

• Using MMU with STMs can lower their sequential overhead

• We proposed PGTSM as proof of concept

• PGSTM outperforms TML in low contention scenarios

• Our preliminary results are promising


technologyfrom seed

Future works

• Evaluating with non-trivial benchmarks

• Supporting multiple writers

• Using finer grained conflict detection

• Upgrading to a generic accelerator layer that runs on top of any STM


technologyfrom seed


Thank you!

Amin Mohtasham

Documents

Exploiting Off-the-Shelf Virtual Memory Mechanisms to Boost Software Transactional Memory