System Programming (CSE4009 - 24448) - Project 2 - WL-Aware GC
System Programming (CSE4009 – 24448)
Project 2 – WL-Aware GC
Overview
• Goal
• You observe how wear imbalance shortens the device lifetime
• You modify the existing GC mechanism to take wear leveling into account
• You explore the impact of varying a parameter of your modified GC mechanism
• Outcome
• Implementation of a new (WL-aware) GC mechanism
• Evaluation of the modified GC mechanism (in terms of the device lifetime)
• Submission
• Write a team slide (in Korean or English) and submit it (in pdf format) with your code to LMS
• Deadline: by midnight on Dec. 10 (Sunday)
• Each team has a individual meeting (evaluation interview) with me on Dec. 8, 11, 12, or 15
• Grading (a total of 50 points)
• Slides and code: 20 points (the details can be found in the following slides)
• Interview: 10 points
• Peer review: 20 points
WL-Aware GC (1)
• WL mechanisms can be divided into two groups: dynamic and static WL
• Static WL triggers explicit data movement operations, which may be challenging to you
• We will implement a simple dynamic WL mechanism
• The current implementation of GC victim block selection
• Line (a group of blocks from different LUNs) is the unit of GC
• The line which include the minimum number of valid pages is selected as a victim lime
• Such a decision is to minimize the GC overhead (coming from the valid page migration)
• However, doing so may not be a promising approach in terms of device lifetime
-
If cold data are accommodated in a few specific lines, they would not be selected as victim
lines, since few page will be invalidated
-
However, the other lines will continue to be selected as victim lines, and their erase counts will increase
-
Consequently, the SSD can experience a wear imbalance across different lines
• How about modifying the victim line selection to consider wear-leveling?
WL-Aware GC (2)
• Your can modify the GC victim line selection to be aware of wear-leveling
-
Each candidate line can be evaluate based on the following two criteria
-
(1) The number of valid pages
-
(2) The erase count
-
Considering both the criteria indicates that we want to select a victim line even if it can increase GC overheads (due to its many valid pages), since doing so can increase its erase count (for the purpose of wear-leveling)
• We can define a metric, “victim score”, which can be calculated as follows:
• victim score = (valid_page_count / pages_per_line)*𝛼 + (erase_count / MAX_PE_CYCLES)*𝛽
•𝛼+𝛽=1
• 𝛼, 𝛽 determine which condition do you prefer? Do you want to highlight GC efficiency? Or, do you want to highlight the result of WL?
• By adjusting the those values, you preference can be reflected to the GC mechanism • The line whose victim score is the minimum is selected as a victim
WL-Agnostic GC VS WL-Aware GC • Existing victim line selection
Line 1
block block block block
# of valid pages: 9 Erase count: 16
Line 1 selected
Line 2
block block block block
# of valid pages: 12 Erase count: 3
• Your modified victim line selection
Line 1 # of valid pages: 9 Erase count: 16
block block block block
If 𝛼 = 0.5 and 𝛽 = 0.5 & MAX_PE_CYCLES = 64
Line 1: 0.5*(9/16) + 0.5*(16/64) = 0.406
Line 2: 0.5*(12/16) + 0.5*(3/64) = 0.398
Line 2 selected! (0.406 > 0.398)
Line 2
block block block block
# of valid pages: 12 Erase count: 3
Fixed Device & Workload Configuration
1GB (0.75GB, 25% OP) SSD Setting
Use this setting only
Assume MAX_PE_CYCLES = 64 (when the erase count of any line reaches 64, your SSD is dead)
• fio
-
direct = 1
-
bs = 16k
-
size = 180M
-
numjobs = 4
-
timebased
-
runtime = 1800
-
rw = randrw
-
random_distribution = zipf:1.2
The Contents of Your Slides
-
Your slides should include (i) code-level implementation, (ii) graphs, and (iii) the corresponding analysis
-
You execute the workload by varying 𝛼 & 𝛽 values
• (i)0&1,(ii)0.25&0.75,(iii)0.5&0.5,(iv)0.75&0.25,and(v)1&0 -
[Graph 1] (X-axis) 𝛼 & 𝛽 pair VS (Y-axis) # of host write I/O requests
-
When the erase count of any line reaches 64, your SSD is dead
-
Count the total number of write I/O requests till your SSD is dead
-
Just single graph
-
-
[Graph 2] (X-axis) line number VS (Y-axis) erase count
-
When the erase count of any line reaches 64, your SSD is dead
-
When your SSD is dead, count the erase count of each line
-
Generate this graph for each 𝛼 & 𝛽 pair
-
This graphs can visualize the wear imbalance status of an SSD
-
A total of 5 graphs
-
• •
Grading
A total of 50 points
Slides & code: 20 points
-
Code review: 10 points
-
Graph 1 & its analysis: 5 points
-
Graph 2 & its analysis: 5 points
-
Note that each graph should be followed by the corresponding analysis/explanation
Interview: 10 points (you may receive the following questions)
-
What are the challenges in doing the project?
-
Explain the impact of 𝛼 & 𝛽 values
-
Who contributes the most or the least?
Peer review: 20 points
-
You’ll grade your team members (points 0~20), which is never known to them
-
After the submission, we’ll let you know how to do peer review
•
•
Extra Lab Sessions
• For the team may suffer from securing computing resources, we’ll offer a limited number of lab sessions
• You can use the machines in Building 311- Room 512
• 19:00 ~ 22:00 (3 hours)
• On every Tuesday and Thursday
• You should ask TA to access the room in advance
• Only project-related activities are allowed • Only class students can come and work
