codable

[Python] 이분 매칭 알고리즘(Bipartite Matching)

hin1209 — Sat, 19 Aug 2023 19:33:59 +0900

이분 매칭 알고리즘은 유량 그래프의 특수한 형태이다. 유량 그래프는 다음 포스팅에서 다루기로 하고... 이분 매칭 알고리즘에 대해 알아보자.

이분 매칭 알고리즘을 알아보기 전에, 이분 그래프에 대해 먼저 알고 넘어가야 한다. 이분 그래프란 정점을 두 개의 그룹으로 나누었을 때, 모든 간선의 양 끝 정점이 서로 다른 그룹에 속하는 형태의 그래프를 말한다. 위의 그림에서 보면 파란색 노드의 집합을 X, 빨간색 노드의 집합을 Y로 표현할 수 있고, 따라서 위의 그래프는 이분 그래프이다.

이분 매칭 알고리즘은 위와 같은 이분 그래프에서 최대 매칭의 개수를 찾는 것과 같다. 매칭이란 간선 하나를 선택하는 것을 말하는데, 예를 들어 그림에서 A와 a를 연결하는 간선을 선택하면 (A, a)라는 매칭이 생기는 것이다. 각 노드들은 딱 한 번만 선택이 되어야 하므로, 이 간선을 선택했을 때 A 또는 a와 연결되어 있는 간선은 더 이상 선택이 불가능하다.

이제 이분 매칭 알고리즘의 과정을 살펴보자.

먼저 위의 그림과 같이 (A, a) 매칭을 선택한다.

이후 (B, c) 매칭을 선택한다.

그다음 (C, a) 매칭을 선택하게 되는데, 이때 a는 이미 (A, a) 매칭에 속해있다. 이러한 상황에서는 (C, a) 매칭을 선택하고 원래 있던 (A, a) 매칭을 끊는다.

A는 매칭이 끊어졌기 때문에 아직 남아있는 간선을 추가로 탐색하게 되고, (A, b) 매칭이 선택된다.

이후 (D, a) 매칭이 선택되고, 원래 있던 (C, a) 매칭은 끊기게 된다. 이후 (C, d) 매칭이 새로 선택된다.

마지막 노드 E는 가능한 매칭이 (E, b) 뿐인데, 이 매칭이 선택될 경우 노드 A는 Y의 다른 노드와 매칭이 불가능하기 때문에 노드 E는 매칭이 될 수 없다. 따라서 가능한 최대 매칭은 위의 그림과 같이 네 가지가 선택될 수 있다.

위의 과정을 코드로 나타내면 다음과 같다.

# matched_Y : Y 그룹의 노드와 매칭된 X 노드의 번호
# matched_X : X 그룹의 노드와 매칭된 Y 노드의 번호
def dfs(x):
    visited[x] = True
    for y in graph[x]:
        # y 노드와 매칭된 노드가 없는 경우, x 노드와 매칭
        if matched_Y[y] == 0:
            matched_Y[y] = x
            matched_X[x] = y
            return True
        # y 노드가 이미 매칭이 되어있는 경우, y 노드와 매칭되어 있는 노드가 다른 노드와 매칭이 가능한지 확인
        elif not visited[matched_Y[y]] and dfs(matched_Y[y]):
            # 다른 노드와 매칭이 가능한 경우, y 노드와 x 노드를 매칭
            matched_Y[y] = x
            matched_X[x] = y
            return True
    return False


cnt = 0
for i in range(1, n+1):
    if matched_X[i] == 0:
        visited = [False] * (n+1)
        if dfs(i):
            cnt += 1

이분 매칭 알고리즘 문제로 풀어볼 만한 것들은 아래와 같다.

https://www.acmicpc.net/problem/11375

11375번: 열혈강호

강호네 회사에는 직원이 N명이 있고, 해야할 일이 M개가 있다. 직원은 1번부터 N번까지 번호가 매겨져 있고, 일은 1번부터 M번까지 번호가 매겨져 있다. 각 직원은 한 개의 일만 할 수 있고, 각각

www.acmicpc.net

기본적인 이분 매칭 알고리즘 문제다. 위의 그림에서 X 그룹과 Y 그룹을 각각 직원과 일로 구분해서 풀 수 있다.

https://www.acmicpc.net/problem/11376

11376번: 열혈강호 2

강호네 회사에는 직원이 N명이 있고, 해야할 일이 M개가 있다. 직원은 1번부터 N번까지 번호가 매겨져 있고, 일은 1번부터 M번까지 번호가 매겨져 있다. 각 직원은 최대 두 개의 일을 할 수 있고,

www.acmicpc.net

이 문제는 위의 열혈강호 문제에 딱 한 가지 조건이 추가되었다. 바로 직원 한 명이 최대 두 개까지의 일을 할 수 있는 것인데, 같은 edge를 가진 직원을 하나씩 더 만든다고 생각하고 풀면 된다.

https://www.acmicpc.net/problem/11377

11377번: 열혈강호 3

첫째 줄에 직원의 수 N과 일의 개수 M, 일을 2개할 수 있는 직원의 수 K가 주어진다. (1 ≤ N, M ≤ 1,000, 1 ≤ K ≤ N) 둘째 줄부터 N개의 줄의 i번째 줄에는 i번 직원이 할 수 있는 일의 개수와 할 수 있

www.acmicpc.net

기본적으로 백준의 열혈강호 시리즈는 다 이분 매칭 문제들인 것 같다. 이 문제는 직원들 중 몇 명만이 일을 두 개씩 할 수 있다는 추가 조건이 붙는다. 이때 k명의 직원을 특정하지는 않기 때문에 k명 이내에서는 어떤 직원이든 일을 두 개씩 할 수 있다.

이 문제는 이분 매칭을 총 두 번 하는 방식으로 풀 수 있다. 이때 두 번째 이분 매칭에서는 매칭이 총 k개 생긴 경우 매칭을 종료해야 한다.

[Python] 2020 KAKAO BLIND RECRUITMENT - 블록 이동하기

hin1209 — Sat, 15 Jul 2023 15:05:26 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/60063

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

이번 문제는 2020 카카오 공채 1차 코딩테스트 7번 문제로 출제된 블록 이동하기 문제이다.

이렇게 맵을 탐색하는 문제는 굉장히 흔한데, 그런 문제들과 이 문제의 가장 큰 차이점은 바로 로봇이 한 칸이 아닌 두 칸을 차지한다는 점이다. 또한 로봇이 이동할 때에도 두 칸이 모두 이동할 수 있어야 한다는 제약이 걸려있다. 또 이러한 점을 고려하여 로봇이 회전까지 할 수 있다...

위의 조건들을 고려해 보았을 때, 특정 위치에서 로봇이 할 수 있는 행동은 총 여덟 가지가 나온다.

1. 왼쪽 축을 기준으로 시계 방향 회전

2. 왼쪽 축을 기준으로 반시계 방향 회전

3. 오른쪽 축을 기준으로 시계 방향 회전

4. 오른쪽 축을 기준으로 반시계 방향 회전

5, 6, 7, 8. 상하좌우 이동

위의 조건을 따라 그대로 구현하기만 하면 된다!

하지만 이대로 구현만 하면 같은 상황이 반복될 수 있으므로, 같은 상황에서는 검사를 하지 않도록 조치를 취해야 한다. 나는 dp 테이블을 딕셔너리 형태로 만들어 관리했다. 들어가는 값은 (y1, x1, y2, x2, direction)을 넣었고, 만약 같은 값이 dp 테이블에 이미 존재한다면 검사를 하지 않고 넘어가는 방식으로 구현했다. 이때 같은 상황에서 (y1, x1), (y2, x2)의 좌표만 반전되는 경우를 피하기 위해서 x1이 항상 x2보다 작게 오게끔 하였고, 만약 x1이 x2와 같은 상황에서는 y1이 y2보다 작게끔 해주었다.

코드는 아래와 같다!

from collections import deque

def check_turn(y1, x1, y2, x2, board, direction):
    if direction == 0:
        if board[y1-1][x1] == 0 and board[y2-1][x2] == 0:
            return True
        else:
            return False
    elif direction == 1:
        if board[y1+1][x1] == 0 and board[y2+1][x2] == 0:
            return True
        else:
            return False
    elif direction == 2:
        if board[y1][x1-1] == 0 and board[y2][x2-1] == 0:
            return True
        else:
            return False
    elif direction == 3:
        if board[y1][x1+1] == 0 and board[y2][x2+1] == 0:
            return True
        else:
            return False
        
def solution(board):
    answer = 0
    dx = [1, 0, -1, 0]
    dy = [0, 1, 0, -1]
    robot = [[0, 0], [0, 1], 0, 0]
    q = deque()
    q.append(robot)
    stop = 0
    dp = {}
    while q:
        tmp = q.popleft()
        if tmp[0][0] == len(board) - 1 and tmp[0][1] == len(board) - 1:
            answer = tmp[3]
            break
        if tmp[1][0] == len(board) - 1 and tmp[1][1] == len(board) - 1:
            answer = tmp[3]
            break
        if (tmp[0][0], tmp[0][1], tmp[1][0], tmp[1][1], tmp[2]) in dp:
            continue
        dp[(tmp[0][0], tmp[0][1], tmp[1][0], tmp[1][1], tmp[2])] = True
        
        y1, x1 = tmp[0]
        y2, x2 = tmp[1]
        direction = tmp[2]
        time = tmp[3]
        if direction == 0:
            if y1 > 0 and check_turn(y1, x1, y2, x2, board, 0):
                q.append(([y2-1, x1], [y1, x1], 1, time+1))
                q.append(([y2-1, x2], [y2, x2], 1, time+1))
            if y1 < len(board) - 1 and check_turn(y1, x1, y2, x2, board, 1):
                q.append(([y1, x1], [y2+1, x1], 1, time+1))
                q.append(([y2, x2], [y2+1, x2], 1, time+1))
        elif direction == 1:
            if x1 > 0 and check_turn(y1, x1, y2, x2, board, 2):
                q.append(([y1, x1-1], [y1, x1], 0, time+1))
                q.append(([y2, x2-1], [y2, x2], 0, time+1))
            if x1 < len(board) - 1 and check_turn(y1, x1, y2, x2, board, 3):
                q.append(([y1, x1], [y1, x1+1], 0, time+1))
                q.append(([y2, x2], [y2, x2+1], 0, time+1))
                    
        for i in range(4):
            nx1 = tmp[0][1] + dx[i]
            ny1 = tmp[0][0] + dy[i]
            nx2 = tmp[1][1] + dx[i]
            ny2 = tmp[1][0] + dy[i]
            if 0 <= nx1 < len(board) and 0 <= ny1 < len(board) and 0 <= nx2 < len(board) and 0 <= ny2 < len(board):
                robot = ([ny1, nx1], [ny2, nx2], tmp[2], tmp[3]+1)
                answer = robot[3]
                if board[ny1][nx1] == 0 and board[ny2][nx2] == 0:
                    q.append(robot)
                    
        if stop == 1:
            break
    return answer

[Python] 2023 KAKAO BLIND RECRUITMENT - 표 병합

hin1209 — Sat, 15 Jul 2023 12:08:30 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/150366

프로그래머스

programmers.co.kr

이번 문제는 작년 하반기 카카오 공채 문제로 나왔던 표 병합 문제이다! union-find 문제인데 당시에 문제를 풀 때는 거의 마지막쯤에나 깨달아서 결국 효율성 점수를 받지 못했었다...

union-find 알고리즘 자체가 어려운 편은 아니라 구현만 꼼꼼하게 한다면 충분히 풀 수 있는 문제다. 구현 문제인 만큼 문제를 꼼꼼히 읽고 시작하자!

마치 엑셀을 연상시키는 것 같은 문제였는데, 엑셀과는 달리 멀리 떨어져 있는 셀끼리의 병합도 가능했다. 문제에서 주어지는 셀들이 표 형태이기 때문에 2차원 리스트 형태로 관리해야 했는데, 각각의 element들을 union-find 알고리즘을 사용하기 위해 parent 배열로 만들어줘야 했던 점이 힘들었던 것 같다. 나는 기존의 union-find 함수들을 그대로 사용하기 위해서 2차원 배열의 좌표를 선형적으로 변환해 parent 배열을 만들었다.

문제에서 표의 최대 크기가 50 x 50이라는 제한을 두었기 때문에, parent 배열의 크기도 마찬가지로 51 x 51로 설정하였다. 여기에서 parent 배열의 크기가 50이 아닌 51인 이유는, 셀들의 좌표가 0이 아닌 1부터 시작하기 때문이다. parent 배열에서도 0번 인덱스는 사용하지 않는다.

좌표를 인덱스로 변환하는 과정은, row 번호에는 50을 곱해주고, 이후에 col 번호를 더해주는 방식으로 구현하였다. 역으로 인덱스를 좌표로 변환할 때에는 인덱스를 50으로 나눈 몫을 row 번호로, 나머지를 col 번호로 사용했는데, 이때 col 번호가 50인 경우 나머지가 0으로 나오는 경우가 있었다. 따라서 나머지가 0인 경우 따로 예외 처리를 해주었다.

def find_parent(parent, x):
    if parent[x] != x:
        parent[x] = find_parent(parent, parent[x])
    return parent[x]

def union_parent(parent, a, b):
    a = find_parent(parent, a)
    b = find_parent(parent, b)
    
    parent[b] = a

def solution(commands):
    answer = []
    parent = [0] * (51 * 51)
    graph = [[0] * 51 for _ in range(51)]
    
    for i in range(len(parent)):
        parent[i] = i
    
    for command in commands:
        command = command.split()
        if command[0] == "UPDATE":
            update_command(command[1:], graph, parent)
        elif command[0] == "MERGE":
            merge_cell(parent, graph, int(command[1]), int(command[2]), int(command[3]), int(command[4]))
        elif command[0] == "UNMERGE":
            unmerge_cell(parent, graph, int(command[1]), int(command[2]))
        elif command[0] == "PRINT":
            y, x = int(command[1]), int(command[2])
            parent_idx = find_parent(parent, 50*y+x)
            if parent_idx % 50 == 0:
                value = graph[parent_idx//50-1][50]
            else:
                value = graph[parent_idx//50][parent_idx%50]
            if value == 0:
                answer.append("EMPTY")
            else:
                answer.append(value)
            
    return answer

def convert_to_idx(y, x):
    return 50 * y + x

def check_parent_value(parent, graph, x):
    x = find_parent(parent, x)
    if x % 50 == 0:
        return graph[x//50-1][50]
    return graph[x//50][x%50]

def update_parent_value(parent, graph, x, value):
    x = find_parent(parent, x)
    if x % 50 == 0:
        graph[x//50-1][50] = value
    else:
        graph[x//50][x%50] = value

def update_command(contents, graph, parent):
    if len(contents) == 3:
        idx = convert_to_idx(int(contents[0]), int(contents[1]))
        value = contents[2]
        parent_idx = find_parent(parent, idx)
        if parent_idx % 50 == 0:
            graph[parent_idx//50-1][50] = value
        else:
            graph[parent_idx//50][parent_idx%50] = value
    else:
        prev_value = contents[0]
        update_value = contents[1]
        for i in range(1, 51):
            for j in range(1, 51):
                parent_value = check_parent_value(parent, graph, 50*i+j)
                if parent_value == prev_value:
                    update_parent_value(parent, graph, 50*i+j, update_value)

def merge_cell(parent, graph, r1, c1, r2, c2):
    idx1 = 50 * r1 + c1
    idx2 = 50 * r2 + c2
    parent1 = find_parent(parent, idx1)
    parent2 = find_parent(parent, idx2)
    
    if parent1 == parent2:
        return 
    
    if parent1 % 50 == 0:
        py1, px1 = parent1//50 - 1, 50
    else:
        py1, px1 = parent1//50, parent1%50
    if parent2 % 50 == 0:
        py2, px2 = parent2//50 - 1, 50
    else:
        py2, px2 = parent2//50, parent2%50
    
    value1 = graph[py1][px1]
    value2 = graph[py2][px2]
    
    if value1 == 0:
        graph[py1][px1] = graph[py2][px2]
    
    union_parent(parent, idx1, idx2)
    
def unmerge_cell(parent, graph, r, c):
    group_num = find_parent(parent, 50*r+c)
    parent_value = check_parent_value(parent, graph, 50*r+c)
    unmerge_list = []
    for i in range(1, 51):
        for j in range(1, 51):
            idx = 50*i + j
            if find_parent(parent, idx) == group_num:
                unmerge_list.append((i, j))
    for y, x in unmerge_list:
        graph[y][x] = 0
        parent[50*y+x] = 50*y+x
    graph[r][c] = parent_value

[Python] 2022 KAKAO TECH INTERNSHIP 코딩 테스트 공부

hin1209 — Tue, 11 Jul 2023 20:39:07 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/118668

프로그래머스

programmers.co.kr

이번 문제는 카카오 인턴십 문제로 출제된 코딩 테스트 공부이다! dp 문제는 언제나 구현하는 시간보다 생각하는 시간이 길어지는 것 같다.

나는 항상 dp 문제와 그리디 문제를 헷갈려하는데, 풀 때 먼저 그리디 하게 풀려고 했을 때 직관적인 풀이가 잘 떠오르지 않으면 dp로 푸는 것 같다.

코딩 테스트 공부 문제는 완전 탐색과 dp를 결합한 문제이다. 문제 요구 사항을 살펴보자.

문제에서 초기 알고력, 코딩력이 주어지고 알고리즘 문제 리스트가 주어진다.

알고리즘 문제는 다음과 같이 주어진다.
[문제를 풀기 위한 알고력, 문제를 풀기 위한 코딩력, 풀었을 때 오르는 알고력, 풀었을 때 오르는 코딩력, 푸는 데 걸리는 시간]
문제를 풀면 주어진만큼 알고력과 코딩력이 오르는데, 알고력과 코딩력은 공부를 해서 올릴 수 있다. 이때 시간을 1만큼 사용하면 알고력 또는 코딩력을 1만큼 올릴 수 있다. 문제를 여러 번 풀면 reward가 여러 번 적용된다.

주어진 문제를 모두 풀기 위한 알고력과 코딩력을 갖추는데 걸리는 최소 시간을 구해라.

문제를 처음 봤을 때는 냅색 문제를 떠올렸었다. 냅색 문제를 떠올려보면, 보통 한 가지를 최대화하면서 동시에 나머지 하나는 최소화하는 문제 유형이다. 이 문제도 마찬가지로 알고력과 코딩력을 올리는 동시에 시간은 최소화해야 한다.

이러한 점을 고려하여, 나는 dp를 2차원 배열의 형태로 만들었다. 각각의 row와 column은 알고력과 코딩력을 의미하며, 문제에서 알고리즘 문제가 요구하는 최대 알고력과 코딩력은 각각 150으로 제한이 걸려있었기 때문에 배열의 크기는 151 x 151으로 설정했다. dp에 들어가는 값은 해당 (알고력, 코딩력)까지 도달하는데 걸리는 최소 시간을 의미한다. 따라서 처음에는 초기값을 제외하고는 모두 INF로 설정했다.

이후 (0, 초기 알고력, 초기 코딩력)을 heapq에 넣은 후, 반복문을 돌면서 모든 경우를 계산해 주었다. 여기서 모든 경우란 현재의 알고력과 코딩력을 기반으로 풀 수 있는 문제들을 풀었을 때의 시간과 (알고력, 코딩력)을 계산하는 것을 말한다.

반복문을 종료하는 조건은 힙이 비어있거나, 현재의 (알고력, 코딩력)이 모든 문제를 풀기에 충분한 정도일 때이다. 시간을 기준으로 힙에 삽입했기 때문에, 가장 처음으로 (알고력, 코딩력)이 모든 문제를 풀기 충분할 때가 가장 짧은 시간임을 보장할 수 있다.

코드는 아래와 같다.

import heapq

def solution(alp, cop, problems):
    INF = int(1e9)
    answer = INF
    
    max_alp = 0
    max_cop = 0
    
    for problem in problems:
        max_alp = max(max_alp, problem[0])
        max_cop = max(max_cop, problem[1])
    
    dp = [[INF] * 151 for _ in range(151)]
    dp[alp][cop] = 0
    
    h = []
    heapq.heappush(h, (0, -alp, -cop))
    problems += [[0, 0, 1, 0, 1], [0, 0, 0, 1, 1]]
    problems.sort()
    while h:
        time, alp, cop = heapq.heappop(h)
        alp *= -1 
        cop *= -1
        if max_alp <= alp and max_cop <= cop:
            answer = time
            break
        for problem in problems:
            if alp < problem[0]:
                break
            if cop < problem[1]:
                continue
            next_alp = alp + problem[2]
            next_cop = cop + problem[3]
            if next_alp > 150:
                next_alp = 150
            if next_cop > 150:
                next_cop = 150
            next_time = time + problem[4]
            if dp[next_alp][next_cop] > next_time:
                dp[next_alp][next_cop] = next_time
                heapq.heappush(h, (next_time, -next_alp, -next_cop))
    
    return answer

[Pintos] Project 4 - File System(FAT)

hin1209 — Tue, 30 May 2023 00:55:48 +0900

이번 주는 핀토스의 마지막 주차인 파일 시스템이다. 보통 핀토스는 프로젝트 2와 3이 가장 어려운 편이고, 마지막 프로젝트 4가 쉬운 편이라고 하는데 그렇다고 만만할 정도는 아니었다... 그래도 핀토스에 대한 흐름이 어느 정도 잡혀있어서 그런지 초반에 개념을 잡고 나니 구현은 생각보다 빠르게 진행됐다.

초반에 개념 잡는 게 어려우니 오늘 포스팅은 파일 시스템의 기본 개념에 대해서 다뤄보려고 한다!

Inode

먼저 핀토스가 제공하는 기본 코드에 대해서 살펴보자. 커널에서 파일이나 directory에 접근할 때 항상 inode라는 구조체를 거쳐서 접근하게 된다. inode 구조체를 살펴보자!

/* In-memory inode. */
struct inode
{
	struct list_elem elem;	/* Element in inode list. */
	disk_sector_t sector;	/* Sector number of disk location. */
	int open_cnt;			/* Number of openers. */
	bool removed;			/* True if deleted, false otherwise. */
	int deny_write_cnt;		/* 0: writes ok, >0: deny writes. */
	struct inode_disk data; /* Inode content. */
};

/* On-disk inode.
 * Must be exactly DISK_SECTOR_SIZE bytes long. */
struct inode_disk
{
	disk_sector_t start; /* First data sector. */
	off_t length;		 /* File size in bytes. */
	int is_dir;
	unsigned magic;		  /* Magic number. */
	uint32_t unused[124]; /* Not used. */
};

핀토스에서 사용하는 inode 구조체에는 inode_disk라는 구조체를 멤버 변수로 사용하고 있다. 간략하게 설명하자면 inode는 메모리 공간 상에서만 존재하는 데이터이고, inode_disk는 실제로 하드 디스크에 저장되어 있는 정보이다. 각각의 멤버 변수에 대해 조금 더 자세하게 알아보자.

inode

elem : inode가 open 되었을 때 open 된 inode들을 관리하는 리스트에 삽입하기 위해 있는 변수이다.
sector : inode_disk에 대한 데이터가 저장되어 있는 sector를 의미한다.
open_cnt : 현재 inode를 open 한 프로세스의 개수를 의미한다.
removed : inode가 가리키고 있는 파일의 삭제 유무를 나타낸다. 만약 removed가 true로 설정되면, inode를 참조하고 있는 마지막 프로세스가 inode를 close 할 때 파일 삭제를 진행한다.
deny_write_cnt : 파일의 write를 deny 설정한 횟수를 의미한다.
data : 실제 디스크에 저장되어 있는 inode의 내용이다.

inode_disk

start : 실제 데이터가 저장되어 있는 sector의 시작점을 의미한다.
length : 파일의 길이를 의미한다.
is_dir : 구현 과정에서 추가한 변수로, 현재 inode가 directory인지를 나타내는 변수이다.
unused : inode_disk의 크기를 하드디스크의 한 sector와 맞추기 위한 변수이다. 실제로 사용되지는 않는다.

모든 파일이나 directory는 이 inode를 통해 관리된다. directory 또한 파일처럼 취급하고 따라서 directory에도 파일과 마찬가지로 inode 구조체가 붙는다. 모든 파일이나 directory는 고유한 inode를 가지며, inode가 저장되어 있는 sector를 inumber라고 한다.

위와 같이 ls -i 옵션을 통해 파일의 inumber를 확인해 볼 수 있다. inode_disk는 아주 간략한 정보만 담고 있지만, 실제로 inode는 파일의 권한이나 마지막 수정 시간 등 더 많은 메타데이터를 담고 있다.

위와 같이 stat 명령어를 통해 파일이나 directory의 더욱 자세한 정보를 확인할 수 있다.

How to access File/Directory

이제 이 inode에 담겨있는 정보를 통해 실제 directory나 파일에 접근하는 방법을 알아보자. 하드 디스크가 위의 그림과 같이 있다고 해보자. 아주 간단하게 표현하긴 했지만 위의 그림과 같이 디스크의 맨 앞부분은 예약된 영역으로 사용한다. 이후 우리가 사용할 FAT가 위치하고, 그 뒷부분이 모두 data region이다.

보통 root directory cluster는 그림과 같이 FAT의 바로 뒤에 위치한다. root directory cluster의 안을 조금 더 자세히 들여다보자.

그림과 같이 root directory cluster에는 여러 파일 또는 directory의 directory entry들이 담겨있다. 구조체를 확인하고 넘어가자.

/* A single directory entry. */
struct dir_entry
{
	disk_sector_t inode_sector; /* Sector number of header. */
	char name[NAME_MAX + 1];	/* Null terminated file name. */
	bool in_use;				/* In use or free? */
};

위와 같이 세 개의 변수가 있는 것을 확인할 수 있다.

inode_sector : 파일 또는 directory에 대한 inode가 위치한 sector를 의미한다.
name : 파일 또는 directory의 이름을 의미한다.
in_use : directory 내에서 실제로 사용되고 있는지를 확인하는 flag이다. 만약 false로 설정되어 있다면, 존재하지 않거나 삭제된 파일을 의미한다.

directory 내의 entry들은 모두 크기가 동일하기 때문에, 파일이나 directory를 찾을 때에는 directory entry들을 검사하며 name을 비교하여 찾을 수 있다.

directory entry에 들어있는 내용들을 나타내면 위의 그림과 같다. 각각의 entry들이 모두 파일의 inode 위치와 이름을 가지고 있는 것을 볼 수 있다. 여기서 만약 jungle이라는 이름의 directory로 접근한다고 생각해 보자. 그림에서는 dir1이다.

dir1에 대한 entry를 읽어 들여 inode_sector가 45번인 것을 알아냈다! 이제 디스크의 45번 sector로 접근해 정보를 불러온다. 여기에서 우리는 jungle directory에 대한 data가 56번 sector에 저장되어 있으며, 길이는 58475byte인 것을 알 수 있다.

우리는 이제 위와 같이 jungle directory에 대한 data에 접근할 수 있게 되었다! 현재 접근한 파일은 directory이기 때문에, dir1 data에는 위에서 root directory를 살펴본 것과 같이 directory entry들이 담겨있을 것이다. 파일에 대한 접근 또한 이와 동일하며, 단지 읽어 들일 데이터의 형태만 다를 뿐이다.

FAT(File Allocation Table)

이번에는 위의 그림에서 나와있는 FAT에 대해 알아보자. 기본적으로 핀토스에서는 디스크 sector의 할당 여부를 free_map을 활용하여 나타내고 있다. free_map은 bitmap 자료구조로 구현되어 있으며, sector 할당 요청이 들어왔을 때 bitmap_scan_and_flip 함수를 통해 연속적으로 할당 가능한 sector들을 찾고 bitmap의 bit들을 1로 뒤집는다. 이러한 방식 때문에, 기존의 free_map을 활용한 방식에서는 파일을 만들기 위해서 파일 크기만큼의 연속적인 sector가 비어있어야 했다. 이를 FAT 방식으로 바꾸어 파일을 흩어진 sector들에 나누어 저장하는 방식을 구현하는 것이 프로젝트 4의 과제이다!

FAT에서는 sector들을 관리하기 위해 디스크의 sector를 cluster 단위로 나누어 관리한다.

그림으로 나타내면 대략 위와 같다! 여기에서 우리가 만약 어떤 파일을 만드는데, 총 세 개의 cluster가 필요하다고 해보자. 원래의 free_map 방식이었으면 위의 그림에서 CLUSTER2에서 CLUSTER4 까지를 할당했을 것이다.

그렇다면 같은 상황에서 위와 같이 CLUSTER2와 CLUSTER4가 이미 할당된 상태라면 어떻게 될까? free_map 방식에서는 CLUSTER3은 연속적으로 할당이 불가능하기 때문에 사용할 수 없게 된다. 하지만 FAT 방식에서는 CLUSTER3도 사용할 수 있다!

위와 같이 세 개의 cluster를 요청했을 때, CLUSTER 3, 4, 11을 할당해 준다고 하자. 이때 FAT는 다음과 같이 설정된다.

테이블에서 왼쪽은 테이블의 인덱스, 오른쪽은 해당 인덱스의 value를 나타낸 것이다. 이렇게 다음 내용이 저장되어 있는 cluster를 FAT에 저장함으로써 서로 다른 부분에 데이터가 저장되어 있어도 파일을 연속적으로 읽는 것이 가능해진다. 이때 마지막 cluster는 EOChain 값을 설정하여 파일의 끝을 의미하게 한다.

[Pintos] User VA, Kernel VA

hin1209 — Tue, 23 May 2023 00:25:47 +0900

이번 포스팅에서는 개념에 관한 정리보다는 프로젝트를 진행하면서 궁금했던 점을 위주로 정리해보려고 한다!

프로젝트 3을 진행하다 보면, anon page나 file page에서 swap in 함수로 load_segment 함수를 사용할 일이 생긴다. 이때 load를 할 주소 값을 user virtual address로 넘겨주는 경우와 kernel virtual address로 넘겨주는 경우의 차이가 발생한다.

이 차이가 왜 발생하는지, 또 user virtual address의 경우 kernel virtual address와의 mapping 정보를 page table에 추가해 주었기 때문에 참조가 가능한데, kernel virtual address는 어떻게 바로 참조가 가능한지에 대해 알아보았다.

User Virtual Address & Kernel Virtual Address

저번 포스팅에서도 언급했었지만, 다시 한번 간략하게 정리하고 넘어가려고 한다. 우선 user virtual address는 유저가 사용하는 가상 주소 공간을 말한다. 이 주소 공간은 모든 프로세스가 독립적으로 사용한다. 즉, 프로세스 A가 사용하는 0x1000 주소는 프로세스 B가 사용하는 0x1000 주소와 실제로 매핑되어 있는 물리 프레임이 다르다는 것이다! 이를 통해 프로세스 A에서 프로세스 B가 사용하는 주소인 0x1000에 접근한다고 해서 B가 사용하고 있는 데이터를 얻어오는 것이 불가능해진다. 커널에서는 이러한 방식으로 프로세스 간의 memory protection 기능을 제공하고 있다.

반면에 kernel virtual address는 실제 물리 프레임과 1대 1 매핑이 되어있는 가상 주소 공간을 말한다. 핀토스에서는 KERN_BASE를 기준으로 유저 가상 주소 공간과 커널 가상 주소 공간을 나누고 있으며, KERN_BASE 위의 주소들은 실제 물리 프레임과 1대 1로 매핑이 되어있다.

여기에서 1대 1로 매핑이 되어있다는 것이 무슨 의미일까? 핀토스가 실행될 때의 코드를 한번 살펴보자.

static void
paging_init (uint64_t mem_end) {
	uint64_t *pml4, *pte;
	int perm;
	pml4 = base_pml4 = palloc_get_page (PAL_ASSERT | PAL_ZERO);

	extern char start, _end_kernel_text;
	// Maps physical address [0 ~ mem_end] to
	//   [LOADER_KERN_BASE ~ LOADER_KERN_BASE + mem_end].
	for (uint64_t pa = 0; pa < mem_end; pa += PGSIZE) {
		uint64_t va = (uint64_t) ptov(pa);

		perm = PTE_P | PTE_W;
		if ((uint64_t) &start <= va && va < (uint64_t) &_end_kernel_text)
			perm &= ~PTE_W;

		if ((pte = pml4e_walk (pml4, va, 1)) != NULL)
			*pte = pa | perm;
	}

	// reload cr3
	pml4_activate(0);
}

위의 코드를 보면, 주석에도 적혀있는 것처럼 커널의 가상 주소와 실제 물리 프레임 주소 간의 매핑을 진행한다. 이때 매핑 정보는 커널의 page table인 base_pml4에 추가되는 것을 볼 수 있다. 이 코드를 통해 우리는 커널 또한 page table을 가지고 있으며, 그 page table에는 kernel virtual address와 physical frame 간의 1대 1 매핑 정보가 담겨있다는 것을 알 수 있다.

그다음에는 유저 프로세스를 생성할 때, page table을 생성하는 부분을 살펴보자.

우리가 fork 또는 exec 시스템 콜을 호출해서 __do_fork 함수나 process_exec 내의 load 함수에서 pml4_create 함수가 호출된다. 이 함수는 새로운 page table을 생성하는 함수이다. 위의 코드에서 빨간색 네모 박스 부분을 살펴보면, base_pml4에서 값을 복사해 오는 부분을 확인할 수 있다. 이 말은 커널의 page table 정보를 유저 프로세스가 똑같이 복사해 온다는 것을 의미한다. 즉, 유저 프로세스 또한 처음 시작할 때부터 실제 물리 프레임과 1대 1로 매핑되어 있는 kernel virtual address의 정보가 page table에 담겨있다는 것을 의미한다. 이를 통해 위에서 언급했던 의문들이 해소될 수 있다.

먼저 CPU가 특정 주소값으로 접근할 때는 항상 page table을 거쳐간다. 이는 CPU가 받은 주소값이 실제 물리 프레임과 매핑되어 있는 주소인지, 아니면 page table을 통해 kernel virtual address를 얻어와야 하는 주소인지 알 수 없기 때문이다. 따라서 모든 주소에 접근할 때 항상 page table을 거쳐가고, 이에 따라 모든 프로세스들은 kernel virtual address가 물리 프레임과 매핑되어 있는 정보를 page table에 담을 필요가 있다. 이는 kernel mode에서 프로세스가 kernel virtual address에 접근해야 하는 상황이 발생할 수 있기 때문이다.

따라서 우리가 user virtual address에 write 작업을 하면, user virtual address에 해당하는 page table entry의 dirty bit이 활성화되고, kernel virtual address에 write 작업을 하면 kernel virtual address에 해당하는 page table entry의 dirty bit이 활성화되는 것이다. 이를 통해 user virtual address에 해당하는 page table entry의 dirty bit을 활성화시키지 않으면서, 페이지에 값을 쓰는 것이 가능해진다. 이러한 상황은 페이지에 초기 내용을 load 하는 과정에서 발생한다. load 과정에서는 파일을 실행하기 위한 정보가 쓰이는 것이므로, 엄밀히 따지면 user의 write 작업이라고 보기 힘들다. 따라서 load 과정에서 dirty bit이 활성화되는 것은 적절하지 않으며, 우리는 kernel virtual address를 통해 page에 값을 써주어 user page entry의 dirty bit이 활성화되는 것을 방지하였다.

다음 내용을 이어가기에 앞서, virtual address의 구조를 조금 살펴보고 가자. 상위 비트 값들은 페이지 테이블에 접근하기 위한 offset이나 pointer인데, 이와 관련한 내용들은 docs의 introduction에도 잘 나와있고, 잘 정리해 둔 글들도 많기 때문에 이번 포스팅에서 주로 다루는 내용인 physical offset에 관해서만 언급하고 넘어가겠다.

우리가 virtual address를 통해 얻고자 하는 것은 physical frame의 address이다. 하지만 위의 virtual address structure를 보면 상위 48 비트는 실제 frame의 address와는 직접적인 연관이 없음을 알 수 있다. 반면 하위 12 비트의 physical offset은 우리가 return 값으로 받기 원하는 frame의 address에 직접적으로 쓰이는 값이다. 이를 통해 알 수 있는 것이 하나 있는데, 바로 page table entry에 저장되는 physical frame address의 하위 12 비트는 아무런 쓸모가 없다는 것이다! 왜냐하면 우리가 page table entry에 접근하여 상위 48 비트만큼을 실제 물리 주소로 사용하고, 하위 12 비트는 버리고 나서 인자로 들어온 virtual address의 하위 12 비트를 사용하기 때문이다.

하지만 이렇게 쓸모없는 12 비트조차도 쓸모 있게 사용하기 위해, 우리는 page table entry의 하위 12 비트를 각종 flag를 나타내기 위해 사용한다. 이 정보는 include/threads/pte.h 파일에 나와있다.

Intel® 64 and IA-32 Architectures Software Developer’s Manual

위의 그림은 인텔의 공식 문서에 나와있는 내용이다. pte.h 보다 조금 더 보기 편하게 정리되어 있어 가져왔다. 우리가 프로젝트 3을 하면서 신경 써야 할 flag는 다음과 같다.

0번 bit : 현재 페이지가 page table에 존재하는지를 나타내는 flag이다. 1이면 page table에 존재하는 것.
1번 bit : 현재 페이지가 read only page인지를 나타내는 flag이다. 값이 0이면 read only임을 나타내고, 만약 앞의 present bit이 0이면 이 값은 아무 의미도 가지지 않는다.
2번 bit : 현재 페이지가 kernel만 접근 가능한 페이지인지, 아니면 user/kernel 모두 접근 가능한 페이지인지를 나타내는 flag이다. 만약 값이 0이면 kernel만 접근 가능한 페이지이다.
5번 bit : 현재 페이지에 접근한 적이 있는지를 나타내는 flag이다. 우리가 가상 주소를 통해 어떤 데이터에 접근하면, CPU가 자동으로 page table entry에서 access bit을 1로 활성화시켜 준다.
6번 bit : 현재 페이지에 write 작업이 수행된 적이 있는지를 나타내는 flag이다. 유저 프로그램에서 가상 주소를 통해 write 작업을 하면, access bit과 마찬가지로 CPU가 자동으로 dirty bit을 1로 활성화시켜 준다.

실제로 kernel virtual address에 대한 매핑 정보가 유저 프로세스의 page table에도 존재하는지 확인해 보기 위해 printf로 pte 값을 출력해 보았다. pml4_get_page 함수를 통해 값을 얻어오면, 실제 물리 프레임과 매핑되어 있는 virtual address를 return 하기 때문에 flag를 확인할 수 없다. 그래서 pml4_get_page 내부에서 printf를 통해 pte 값을 출력해 보았다. 먼저 user virtual address 영역에 있는 buffer를 통해 kva 값을 얻어오고, 다시 kva 값을 통해 pgae table에서 kva에 해당하는 page table entry를 찾아주었다. 그 결과 두 개의 pte 값을 얻을 수 있었고, 각 pte 값들을 이진수로 변환한 결과 위의 그림과 같이 나왔다. 이때 buffer로 찾은 page는 3번 비트가 1로 활성화되어 있어 user page임을 알 수 있었고, 반면에 kva 값을 통해 찾은 page는 3번 비트가 0으로 꺼져있어 kernel page 임을 알 수 있었다.

위와 같은 과정을 통해 결론적으로 user virtual address와 kernel virtual address 모두 둘을 구분하지 않고 CPU에서 주소에 접근할 때는 항상 page table에 접근하여 주소값을 얻어온다는 것을 알게 되었다. 프로젝트 3의 경우 시간이 조금 여유롭게 남았기 때문에 이전 프로젝트들보다 좀 더 근본적인 궁금증을 해결하는데 집중했던 것 같다. 덕분에 가상 메모리와 페이지 테이블에 대해 조금 더 깊은 이해를 할 수 있게 되었던 것 같다!

[Pintos] Project 2 - System Call(fork, wait, exec, exit)

hin1209 — Sat, 20 May 2023 20:03:40 +0900

드디어 대망의 프로세스 관련 시스템 콜이다..! 앞에서 소개했던 파일 입출력 관련 시스템 콜은 거의 래핑 함수 위주여서 구현이 어렵지는 않았던 반면, 프로세스 관련 시스템 콜들은 구현할 양도 앞의 포스팅에 비해 많은 편이고 무엇보다도 개념 자체가 쉽게 와닿지 않아 많이 어려웠다고 느꼈다.

프로세스와 관련된 시스템 콜은 fork, exit, exec, wait 으로 총 네 가지가 있다. 이 파트가 특히 어려웠던 점은, 네 개의 시스템 콜 중 하나라도 제대로 구현이 되어있지 않으면 거의 모든 프로세스 시스템 콜 테스트가 통과되지 않아 네 개를 모두 구현하고 나서야 결과를 확인할 수 있었다는 점이다. 구현할 양도 꽤나 많은 편이라 네 개를 모두 구현하고 나서 문제가 생기면 그 문제를 찾기가 꽤나 힘들어진다... 특히 fork가 구현되고 나서부터는 동기화 문제도 발생하기 때문에 디버깅이 아주 힘들어진다.

Fork

fork 시스템 콜은 현재 프로세스와 완전히 동일한 프로세스를 하나 더 만드는 시스템 콜이다. fork 함수의 리턴 값은 크게 세 가지 종류로 나눌 수 있는데, 정리해보면 아래와 같다.

fork()의 return value

1. Negative Value : 자식 프로세스가 정상적으로 만들어지지 않았을 때를 의미한다.
2. Zero : 새로 만들어진 자식 프로세스가 받는 값이다. fork를 호출한 부모 프로세스와 새로 만들어진 자식 프로세스를 구분하기 위해 자식 프로세스에게는 0을 리턴한다.
3. Positive Value : 자식 프로세스가 정상적으로 만들어졌을 때, 부모 프로세스가 받는 리턴 값이다. 자식 프로세스의 pid 값이 리턴된다.

부모와 자식의 리턴 값이 다르다는 것이 무슨 의미일까? 아래의 예시를 보면서 이해해보자!

GeeksforGeeks fork 예시

위와 같은 코드를 실행한다고 해보자. forkexample() 함수가 실행되면 함수 안에서 fork()를 호출하는 것을 볼 수 있다. 조건문을 보면 fork()의 리턴 값을 기준으로 분기되는 것을 볼 수 있는데, 분기 조건이 fork()의 리턴 값이 0인지를 확인하는 것이다. 그렇다면 부모 프로세스가 fork를 통해 자식 프로세스를 만들면 어떻게 될까?

fork 시스템 콜을 호출하면 자식 프로세스는 부모 프로세스의 context 까지 동일하게 복사를 하기 때문에, 자식 프로세스는 부모 프로세스가 마지막으로 실행하던 코드부터 실행하게 된다. 이때 부모의 마지막 context가 fork() 함수를 호출했을 때 이므로, 자식 또한 fork() 함수가 종료된 시점부터 코드를 실행한다. 이때 fork 함수가 끝난 뒤에 코드를 실행하는 프로세스가 fork 함수를 원래 호출했던 부모 프로세스인지, 아니면 fork 함수를 통해 새로 만들어진 자식 프로세스인지를 구분하기 위해 fork()의 리턴 값을 자식에게는 0으로 리턴한다.

따라서 부모와 자식이 각각 코드를 더 실행하게 되면, if문에서 분기처리되어 위의 그림과 같이 실행된다.

핀토스에서 fork를 구현할 때 주의해야 할 점이 있다. 위의 그림과 같이 fork에서는 자식 프로세스가 부모 프로세스의 context를 복사해 오는 과정이 필요하다. fork는 시스템 콜이므로 유저 프로그램에서 fork를 호출하면 먼저 syscall_handler 함수로 진입하게 된다.

핀토스에서 thread 구조체에는 context switching을 위해 인터럽트 프레임을 따로 저장해둔다. 이 인터럽트 프레임은 context switching이 발생할 때마다 값이 바뀐다. 이제 fork의 진행 과정을 살펴보자. 먼저 유저 프로그램에서 fork 시스템 콜을 호출하고, syscall_handler로 진입하게 된다. 이때 syscall_handler의 인자로 user context의 interrupt frame이 전달된다. 이후 fork 과정에서 부모 프로세스는 자식 프로세스를 thread_create() 함수를 통해 생성하고, 자식 프로세스가 부모 프로세스의 리소스를 모두 load 할 때까지 sema_down을 통해 block 상태로 대기하게 된다. 여기에서 자식 프로세스 또는 또 다른 프로세스로 context switching이 발생하게 되는데, 위에서 언급했다시피 context switching에 의해 부모 프로세스의 interrupt frame이 바뀌게 된다. 부모 프로세스가 커널의 코드를 실행하는 도중에 context switching이 발생하여 interrupt frame이 바뀐 것이기 때문에, 부모의 interrupt frame에는 kernel의 context가 담겨있다. 따라서 자식 프로세스가 부모 프로세스의 리소스를 복사하는 과정이 담겨있는 __do_fork 함수에서 부모의 user context interrupt frame을 가져오기 위해서는 다른 방법이 필요하다..! 단순히 부모 프로세스에 접근해 parent->tf와 같은 방식으로 부모의 interrupt frame을 가져오면 kernel context의 interrupt frame을 가져오게 된다. 나는 thread 구조체에 interrupt frame을 저장하는 변수를 하나 더 만들어 syscall_handler에 들어올 때마다 user context의 interrupt frame을 해당 변수(parent_if)에 저장하고, __do_fork 함수에서는 부모 스레드의 parent_if를 가져와 값을 복사해 주는 방식으로 구현했다.

Wait

다음으로 살펴볼 시스템 콜은 wait이다. 파라미터로 기다릴 프로세스의 pid 값이 들어가며, 해당 프로세스가 종료될때까지 다른 일을 하지 않고 멈춰있게 하는 시스템 콜이다. 핀토스가 처음에 실행되고 initial thread에서 idle thread를 생성하는 경우에도 wait 시스템 콜과 비슷하게 동작한다. 이때 또한 세마포어를 활용하여 idle thread가 다 만들어지고 스스로 block 될 때까지 initial thread는 기다리게 된다.

wait을 호출한 부모 프로세스는 wait 함수의 리턴 값으로 자식 프로세스의 exit status를 받게 된다. 만약 자식이 정상적으로 종료되었다면exit status는 -1이 아닌 다른 값이 나올 것이고, 비정상적으로 종료되었다면 wait의 리턴 값으로 -1을 받을 것이다. 이를 통해 부모 프로세스는 자식 프로세스가 정상적으로 종료되었는지 확인할 수 있다. 또한 wait 시스템 콜을 통하여 자식이 자신의 종료를 부모에게 알리고, 자식이 할당받은 자원들을 모두 반환한 뒤 종료하는 작업을 추가해주어야 한다! 예를 들면 현재 실행중인 파일을 닫거나, 실행 과정 중에 열었던 파일들을 닫거나 하는 방식이다.

Exec

fork와 거의 짝꿍처럼 쓰이는 시스템 콜이다. fork가 부모의 리소스를 모두 복사해 자식 프로세스를 만드는 시스템 콜이었다면, exec은 현재 실행 중인 context를 버리고 새로운 파일을 실행하는 시스템 콜이다. 프로세스가 옷을 갈아입는 느낌으로 생각하면 이해하기 편하다! exec은 fork와는 달리 새로운 프로세스가 생기는 것이 아니다. exec 시스템 콜은 파라미터로 실행할 파일의 이름을 넘겨준다. 현재 context를 아예 전환하는 함수이므로 가지고 있던 리소스를 지워줘야한다. 이 작업은 process_cleanup 함수에서 해주니까 지금은 넘어가자..! 하지만 열어두었던 파일 디스크립터들은 exec이 호출되어도 계속 가지고 간다.

Exit

마지막으로 exit 시스템 콜이다. fork와 exec이 자주 같이 쓰이는 것처럼 exit은 wait과 관련이 깊다. exit 시스템 콜은 현재 프로세스의 exit status를 출력하고 프로세스가 가지고 있던 리소스를 모두 지워주는 시스템 콜이다. 또한 프로세스가 종료할 때 부모 프로세스에게 자신의 종료를 sema_up을 통해 알린다.

wait과 exit의 큰 흐름을 보면 위의 그림과 같다. 위의 그림처럼 구현하면서 의문점이 하나 들 수 있다. 바로 굳이 왜 child process를 exit_sema에서 다시 block 상태로 만드는걸까? 이러한 이유는 부모 프로세스가 child list에서 해당 프로세스를 지워야하는데, 만약 child가 sema_down을 통해 block 되지 않는다면 먼저 모든 리소스를 free 해주었을 수도 있기 때문이다. 따라서 child process를 진짜 destroy 하기 전에 먼저 sema_down을 통해 block 상태로 만든 후, parent process에서 child process에 관한 모든 정보를 지운 뒤 child process가 destroy list에 들어가야 한다.

[Pintos] Project 3 - Memory Management

hin1209 — Tue, 16 May 2023 01:56:56 +0900

이번 주는 가상 메모리와 관련된 과제를 진행하였다. VM 파트는 크게 Memory Management, Anonymous Page, Stack Growth, Memory Mapped Files, Swap in/out으로 구분되며 extra로 Copy-on-Write까지 있다.

이번 포스팅에서는 위의 내용들 중에서 Memory Management 파트에 대해 다뤄볼 예정이다.

User Pool & Kernel Pool

사실 memory management 파트에서는 구현할 부분이 다른 파트에 비해 많지는 않은 편이다. 다만 초반에 코드의 흐름을 잡기가 힘들고, 가상 메모리 개념 자체가 잘 와닿지 않기때문에 핀토스의 메모리 구조와 프레임 할당 방식에 관해 중점적으로 다뤄볼 것이다.

우선 핀토스는 아래 그림과 같이 물리 메모리 영역을 유저 풀과 커널 풀의 두 가지 영역으로 나눈다.

테스트에서는 대부분 물리 메모리 영역을 20MB로 잡기 때문에 그림에서도 20MB로 표현했다. 기본적으로 커널 풀과 유저 풀은 각각 물리 메모리의 절반을 차지한다.

우리가 핀토스에서 사용하는 palloc 관련 함수들이 바로 이 물리 메모리 영역을 할당받는 함수이다. threads/palloc.c 파일을 보면 자세히 기술되어 있다.

핀토스에서 메모리를 할당할때에는 무조건 페이지 단위로 맞춰서 메모리 할당을 진행한다. 페이지의 크기는 4096바이트이며, 따라서 모든 페이지의 주소 값은 4096의 배수 형태로 나타나고, 이로 인해 주소값에서 하위 12비트는 페이지의 오프셋을 나타낸다. 물리 메모리 영역을 페이지 크기로 쪼개어 놓은 것을 앞으로 프레임이라고 부르자!

Pintos Virtual Address

우리가 핀토스에서 사용하는 모든 주소 값들은 Virtual Address이다. 즉, palloc을 통해 할당받는 주소 값들 또한 모두 가상 주소이고, 실제로 물리 메모리의 주소 값을 참조하는 일은 없다. 여기까지 왔으면 아마 스레드 구조체의 주소 값을 많이 찍어봤을 텐데, initial thread의 주소 값을 찍어보면 KERNEL_BASE와 같은 0x8004000000을 볼 수 있을 것이다. 핀토스는 init.c 에서 처음 시작할 때 KERNEL_BASE부터 시작하여 KERNEL_BASE + (물리 메모리의 크기)까지 실제 물리 메모리와 mapping 작업을 진행한다. 또한 위에서 유저 풀과 커널 풀에 대해서 이야기했는데, 사실 유저 풀과 커널 풀도 물리 메모리에서 나뉘는 것이 아니라 커널의 가상 주소 영역에서 나뉜다. 그림으로 나타내보면 아래와 같다.

그림에서는 물리 메모리 영역도 두 가지 풀로 나눠뒀는데, 실제로 물리 메모리가 나뉘어져 있지는 않다. 다만 커널의 가상 주소 영역을 유저 풀과 커널 풀로 나누어 매핑하기 때문에 물리 메모리에도 그러한 영역이 나타나는 것.

include/threads/vaddr.h 파일을 보면, is_kernel_addr 이라는 매크로 함수가 있는 것을 볼 수 있다. 인자로 들어온 주소가 커널 영역의 주소, 즉 물리 프레임과 직접 매핑이 되어 있는 주소인지 아니면 유저 영역의 주소인지를 확인해 주는 함수이다. 판단 방법은 인자로 들어온 주소가 KERNEL_BASE보다 큰지 작은지 판별하는 것이다. 그런데 지금 그림에서는 커널 영역의 주소만이 물리 프레임과 매핑이 되어있다. 여기에서 유저 영역의 가상 주소까지 표현하면 다음과 같아진다.

그림과 같이 가상 메모리가 실제 물리 메모리에 비해 아주 큰 것을 볼 수 있다. Kaist-Pintos에서는 64비트 운영체제를 사용하고, 64비트 중 총 48비트를 가상 주소를 표현하는데 사용한다. 따라서 가상 주소로 표현할 수 있는 주소 공간은 무려 256TB이다!

이렇게 방대한 가상 주소 공간에 비해 실제 물리 메모리는 아주 작다. 프로젝트 3에서는 유저가 이렇게 방대한 가상 메모리 공간을 혼자 모두 사용하고있다고 착각하게 만드는 것이 목표이다!

Page Table

위의 그림은 핀토스에서 사용하는 Page Table 구조를 나타낸 것이다. 가상 주소를 해석할때 비트의 자릿수를 나누어 해당 테이블에서의 offset으로 활용하는 것을 볼 수 있다. CPU는 CR3 레지스터에 세팅된 값을 읽어 PML4 Table의 위치를 얻어오고, 주소의 offset 값을 활용해 최종적으로 물리 메모리의 주소를 얻어내는 것을 볼 수 있다.

핀토스의 코드를 보면, process_activate 라는 함수가 있는 것을 알 수 있는데, 이 함수는 프로세스가 처음 실행되거나 context switching이 발생하는 상황에서 호출된다. 이 함수는 CR3 레지스터의 값을 context switching이 발생한 후 CPU를 점유하게 되는 스레드의 PML4 값으로 바꿔주는 역할을 한다.

우리가 프로젝트 3을 진행하기 전에, 이미 핀토스에는 이러한 페이지 테이블이 존재한다. 하지만 기존 페이지 테이블의 가장 큰 문제점이 있는데, 바로 가상 주소 공간이 실제 물리 메모리의 공간만큼 할당이 되면 더 이상 메모리를 할당하지 못한다는 것이다! 이번 과제는 여러 가지 기법들을 통해서 유저 프로그램이 실제 물리 메모리의 공간보다 더 큰 가상 메모리 공간을 모두 사용하는 것처럼 느끼게 하는 것이다.

Supplemental Page Table

우리가 첫번째로 구현해야 할 자료구조이다. 여러 가지 방법으로 구현할 수도 있겠지만 나는 Hash Table 형태로 구현했다. 그렇다면 Supplemental Page Table은 무엇이고, 이미 Page Table이 존재하는데 이 자료구조가 왜 필요할까?

Supplemental Page Table은 기존 페이지 테이블을 조금 더 보완하는 기능을 한다. 기존의 페이지 테이블과 가장 다른 점을 꼽자면, 페이지 테이블은 실제 물리 메모리를 할당받은 페이지들에 대한 정보만 가지고 있지만, Supplemental Page Table은 실제 물리 메모리를 할당받지 못한 페이지들 또한 가지고 있다는 점이다!

그림으로 살펴보자면, 위의 그림이 기존의 페이지 테이블이다.

그리고 위의 그림이 Supplemental Page Table이다. 실제 물리 메모리에 없는 페이지의 정보도 가지고 있고, 그러한 페이지의 값은 실제로 Memory 보다는 조금 더 멀리 있는 Disk에 저장되어 있다. 페이지의 종류에 따라 쫓겨나는 장소가 Swap Disk 또는 File로 달라지는데, 이 내용은 추후에 포스팅할 예정이다!

이렇게 핀토스의 가상 메모리 구조와 우리가 구현해야 할 Supplemental Page Table에 대해 알아보았다! 핀토스 코드에서 threads/mmu.c 파일에 기존 페이지 테이블의 코드가 아주 상세히 나와있으니, 궁금하면 참고해도 좋다.

[Pintos] System Call - File I/O

hin1209 — Tue, 9 May 2023 01:17:29 +0900

핀토스 프로젝트 2의 시작은 시스템 콜부터다. 사실상 argument passing은 몸풀기... 문제는 몸풀기 수준이었던 argument passing조차도 쉽지만은 않았다는 거..!

이번 포스팅에서는 시스템 콜 중에서 파일 입출력과 관련된 시스템 콜들을 다뤄볼 예정이다. 저번에 웹 프록시 서버를 구현할 때 소켓을 파일로 추상화하여 소켓에게도 파일 디스크립터가 붙었는데, 이번에도 파일 디스크립터 개념을 사용한다. 파일 디스크립터와 관련해서는 다뤘던 포스팅이 있으니 참고하자.

https://codable.tistory.com/19

[Computer System] File Descriptor

File Descriptor 유닉스 시스템에서는 많은 것들을 파일로 관리한다. 정규 파일들뿐만 아니라 디렉터리, 소켓, 기타 입출력 장치들 모두 파일의 형태로 취급하는데, 이 파일들을 구분하기 위해 파일

codable.tistory.com

File I/O System Call 목록

1. create
2. remove
3. open
4. filesize
5. read
6. write
7. seek
8. tell
9. close

파일 입출력 관련 시스템 콜을 구현하기 전에, 각 스레드들은 고유한 file descriptor table을 가지고 있어야 한다. 매번 쓰기에 너무 기니까 포스팅에서는 파일 테이블이라고 언급하겠다. 파일을 open 하면 새로 연 파일을 파일 테이블에 추가해 주고, 추가한 위치의 인덱스가 file descriptor라고 알려주어야 한다. 이를 위해 스레드 구조체에 파일 테이블을 추가해 주는데, 이때 파일 테이블을 struct file *fdt[128]과 같이 포인터들을 담은 배열 형태로 선언하면 스레드 구조체의 크기가 너무 커지게 된다! 이를 방지하기 위해 스레드 구조체에는 파일 테이블의 시작 주소만 가지고 있을 수 있게끔 struct file **fdt 형태로 선언해두고, 스레드가 생성될 때 파일 테이블을 동적으로 할당받게끔 해주자.(palloc)

사실 파일 입출력 관련 시스템 콜들은 대부분이 wrapping 함수의 형태를 띠고 있기 때문에 구현에서 크게 어려운 부분은 없었다. 예외 처리만 조금 신경 써서 해주자!

File I/O System Call

1. create(const char *file, unsigned int initial_size)

첫번째로 create 함수이다. 생성할 파일의 이름과 만들 파일의 사이즈를 파라미터로 받고, 디스크에 해당 이름으로 파일을 만드는 시스템 콜이다. 파일 생성에 성공하면 true를, 실패하면 false를 리턴한다. filesys_create 함수를 통해 구현할 수 있다.

2. remove(const char *file)

지울 파일의 이름을 파라미터로 받고, 디스크에서 해당 이름과 같은 이름을 가진 파일을 지우는 시스템 콜이다. 파일 삭제에 성공하면 true를, 실패하면 false를 리턴한다. filesys_remove 함수를 통해 구현할 수 있다.

3. open(const char *file)

파라미터로 받은 file과 같은 이름을 가진 파일을 디스크에서 찾아 연다. filesys_open 함수를 통해 구현할 수 있으며, 파일을 정상적으로 열지 못한 경우 -1을 리턴한다.

4. filesize(int fd)

파라미터로 크기를 구할 파일의 파일 디스크립터를 받는다. 해당 파일 디스크립터에 존재하는 파일의 크기를 리턴하는 함수이다. file_length 함수를 통해 쉽게 구현할 수 있다. 만약 파일을 찾지 못하면 -1을 리턴한다.

5. read(int fd, void *buffer, unsigned int size)

read와 write 함수는 다른 시스템 콜들과는 다르게 락을 활용해야 한다. 파일을 읽는 도중, 또는 파일에 값을 쓰는 과정에서 다른 스레드가 파일에 접근하여 값을 바꿔버릴 수 있으므로, 한 파일에는 하나의 스레드만 접근할 수 있게 하기 위해 락을 사용한다.

파라미터로 파일의 디스크립터 fd, 파일에서 값을 읽어 저장할 buffer, 읽어들일 값의 크기인 size를 받아온다. read의 경우 standard input에서 값을 읽어올 수 있는데, 이 경우 파일 디스크립터 값이 0이다. standard input에서 값을 읽어오는 경우 input_getc 함수를 통해 구현할 수 있고, 다른 파일을 열어서 읽는 경우 file_read 함수를 통해 구현할 수 있다. 파일을 제대로 읽어오지 못하는 경우 -1을 리턴하며, 다른 경우에는 읽어온 값의 크기를 리턴한다.

6. write(int fd, void *buffer, unsigned int size)

read와 마찬가지로 락을 사용하여 구현해야한다. 값을 쓸 파일의 디스크립터 fd, 쓸 값이 들어있는 buffer, 쓸 값의 크기인 size를 파라미터로 받는다. write도 read와 비슷하게 standard output에 값을 쓸 수 있다. 이때 파일 디스크립터 값은 1이며, 콘솔에 값을 쓰는 경우에 해당한다. 함수는 putbuf를 통해 구현할 수 있으며, 다른 파일에 값을 쓰는 경우에는 file_write 함수를 통해 구현할 수 있다. 파일에 값을 쓰지 못한 경우에는 -1을 리턴하며, 값을 쓴 경우에는 쓴 값의 크기를 리턴한다.

7. seek(int fd, unsigned int position)

파일의 offset을 position으로 바꿔주는 함수이다. file_seek 함수를 통해 구현할 수 있다. void 형태로 리턴 값이 없다.

8. tell(int fd)

파일의 offset 값을 리턴하는 함수이다. 존재하지 않는 fd 값이 들어오거나 이미 close 한 파일을 찾는 경우 -1을 리턴한다. file_tell 함수를 통해 구현할 수 있다.

9. close(int fd)

open으로 열었던 파일을 닫는 함수이다. file_close를 통해 구현할 수 있으며, void 형태의 함수로 리턴 값은 없다.

About Memory Allocation

프로젝트 2에는 메모리 누수를 체크하는 multi-oom 테스트가 존재한다. 여기서 open 시스템 콜이 굉장히 많이 호출되는데, 열었던 파일을 제대로 닫아주지 않으면 메모리 누수가 발생하여 테스트를 통과하지 못하게 된다. 처음에 원인이 파일 I/O system call인 open과 close에 있다고 생각하여 조금 자세히 들여봤었다.

file_open

struct file *
filesys_open (const char *name) {
	struct dir *dir = dir_open_root ();
	struct inode *inode = NULL;

	if (dir != NULL)
		dir_lookup (dir, name, &inode);
	dir_close (dir);

	return file_open (inode);
}

file_open 함수를 보기 전에, filesys_open 함수를 먼저 보자. 위의 코드를 보면 파일을 open하기 전에 먼저 디렉터리에서 파일을 찾는 것을 볼 수 있다. 파일이 존재하는 inode를 찾아 그 inode를 파라미터로 넘겨 file_open 함수를 실행시키는 것을 볼 수 있다.

struct file *
file_open (struct inode *inode) {
	struct file *file = calloc (1, sizeof *file);
	if (inode != NULL && file != NULL) {
		file->inode = inode;
		file->pos = 0;
		file->deny_write = false;
		return file;
	} else {
		inode_close (inode);
		free (file);
		return NULL;
	}
}

file_open 함수의 코드이다. filesys/file.c 에 적혀있다. 코드를 보면 파일을 열때 calloc을 통해 메모리를 동적으로 할당받는 것을 볼 수 있다. 새로 할당받은 파일과 inode를 연결하여 파일 구조체가 실제 값을 참조할 수 있게 해 주었다. 여기에서 동적 할당이 이루어지기 때문에 파일을 닫거나 스레드가 종료할 때 할당받은 파일들을 모두 free 해주어야 한다고 생각했다.

file_close

/* Closes FILE. */
void
file_close (struct file *file) {
	if (file != NULL) {
		file_allow_write (file);
		inode_close (file->inode);
		free (file);
	}
}

file_close 함수는 file_open 과는 다르게 wrapping 함수가 없었다. 파일 구조체의 주소값을 인자로 받아 free 해주는 함수이다. 중간에 파일의 inode도 close를 해준다. 아마 프로젝트 4에서 좀 더 자세히 다룰 것 같아서 더 깊게 파보지는 않았다. 이렇게 file_close 함수에서 할당받은 메모리를 반환하는 과정을 확인할 수 있었고, 이를 통해 스레드가 갑자기 비정상적으로 종료하거나 아니면 정상적으로 종료하는 상황에서도 열었던 파일들에 대해 close를 진행해 주어야겠다는 생각을 했다. 물론 원인이 여기는 아니었지만... multi-oom 테스트와 관련한 메모리 누수 문제는 다음 포스팅에서 다루도록 하겠다. 아무튼 원인이 여기가 아닐지라도 스레드가 종료할 때 파일 테이블에 존재하는 모든 파일들을 닫아주는 작업이 진행되어야 한다!

[Pintos] Multi-Level Feedback Queue Scheduler(mlfqs)

hin1209 — Mon, 8 May 2023 23:56:35 +0900

핀토스 프로젝트 1의 extra 과제이다. multi-level feedback queue scheduler의 구현인데, 일단 저번 포스팅에서 소개했던 스케줄러들과 비교해서 어떤 점이 좋은지 살펴보자.

기존 Priority Scheduler의 문제점

기존 우선순위 스케줄러는 저번 포스팅에서도 언급했다시피 우선순위가 낮은 작업이 계속해서 순서가 밀려 CPU를 얻지 못하는 Starvation 현상이 발생할 수 있다는 점이 있었다. 물론 핀토스에서 구현하는 우선순위 스케줄러에서는 priority donation도 있어 우선순위가 낮은 작업도 충분히 실행될 기회를 잡을 수 있지만, 특별히 락을 소유하지 않고 우선순위도 낮은 작업들은 이러한 조정도 받지 못할 수 있다. 이로 인해 task들의 평균 대기 시간이 길어질 수 있는 문제점이 있었다.

Multi-Level Feedback Queue Scheduler(mlfqs)

이를 mlfqs에서는 priority aging 기법을 활용하여 해결한다. priority aging이란 ready list에서 대기를 오래 한 작업일수록 priority를 높여주고 CPU를 오래 쓴 작업일수록 priority를 낮춰주는 식으로 우선순위를 보정하는 기법을 말한다. 이를 통해 처음에 우선순위가 낮은 작업일지라도 오랫동안 순서가 밀리면 후에는 우선순위가 높게 보정되어 기존의 starvation이 발생할 수 있었던 문제를 해결할 수 있다. 또한 mlfqs에서는 스레드들이 nice value를 갖는데, 이 값이 높을수록 다른 스레드에게 순서를 양보하려는 경향이 있다. 정확히 무슨 의미인지는 아래의 식을 보면서 이해해 보자!

Nice Value

nice value는 각각의 스레드별로 존재하는 값이다. 정수 값을 가지며 위에서 언급했다시피 이 값이 클수록 다른 스레드에게 CPU를 양보하려는 경향이 있다. nice value가 가질 수 있는 값의 범위는 아래와 같다.

$$ -20 \leq \text{nice value} \leq 20 $$

범위를 보면 음수 값을 가질수도 있는데, nice value가 음수의 값을 가진다는 것은 다른 스레드로부터 CPU를 뺏어오려는 경향이 강하다는 것을 의미한다. 이 값이 어떤 방식으로 반영되는지는 뒤의 다른 값들의 계산식들을 살펴보면 이해할 수 있을 것이다.

nice value는 스레드 생성 시 설정해 주는 값이며, 직접 nice value를 바꿔주지 않는 이상 스레드가 종료될 때까지 값은 바뀌지 않는다.

Load Avg

nice value나 recent cpu 값과는 달리 모든 스레드가 공유하는 공유 변수이다. 이 값은 nice value와는 달리 실수의 값을 가진다. CPU가 최근 1분 동안 수행 가능한 스레드의 평균 개수를 나타내는 값이다. recent cpu의 값을 계산할 때 감쇠 계수로 쓰인다. 계산식은 아래와 같다.

$$ \text{load avg} = \frac{59}{60}*\text{load avg} + \frac{1}{60} * \text{ready threads} $$

위의 식에서 ready threads는 idle thread를 제외하고 현재 ready list에 있는 스레드와 실행중인 스레드의 개수를 합한 값이다. load avg 값은 초기에 0으로 시작하며, 매 초마다 위의 식에 따라 값을 새로 계산한다.

Recent CPU

위의 load avg 값과 같이 실수의 값을 가진다. nice value와 마찬가지로 스레드마다 개별적으로 가지고 있는 값이며 스레드가 최근에 CPU를 얼마나 많이 사용했는지를 나타낸다. 식은 아래와 같다.

$$ \text{recent cpu} = \frac{2 * \text{load avg}}{2 * \text{load avg} + 1} * \text{recent cpu} + \text{nice} $$

Priority

마지막으로 우선순위를 재조정하는 식을 살펴보자.

$$ \text{priority} = \text{PRI_MAX} - \frac{1}{4} * \text{recent cpu} - 2 * \text{nice} $$

식을 살펴보면 다음과 같은 사실을 알 수 있다.

recent cpu 값이 클수록 우선순위가 많이 낮아진다.
nice 값이 높을수록 우선순위가 많이 낮아진다.

recent cpu의 값이 클수록 최근에 CPU를 많이 사용했다는 의미이므로 값이 크면 우선순위가 많이 낮아지는 것이다. 여기서 load avg는 recent cpu의 감쇠 계수의 역할을 한다고 했다. load avg가 클수록 recent cpu의 감쇠 계수는 1에 가까워지고, load avg가 작을수록 감쇠 계수는 0에 가까워진다. 즉, load avg가 클수록 recent cpu의 값이 천천히 감소한다는 의미이다. 이는 현재 단위 시간당 수행 가능한 스레드의 수가 많을 때는 우선순위의 조정을 조금 천천히 진행하고, 반대로 수행 가능한 스레드의 수가 적을 때는 우선순위의 조정을 빠르게 한다는 의미를 지닌다.

Fixed-point arithmetic

위의 식에서 nice value와 priority를 제외한 값들은 모두 실수 값을 가진다는 것을 살펴보았다. 우리의 핀토스는 부동 소수점 연산을 지원하지 않기 때문에, 고정 소수점 연산(fixed-point arithmetic)을 활용해야 한다.

고정 소수점 연산이란, 위의 그림과 같이 총 32비트의 정수형 자료형에 뒤의 14bit는 소수 부분을, 그 다음 17bit은 정수 부분을, 마지막 1bit은 값의 부호를 나타내는 방식을 말한다.

단 이렇게 고정 소수점을 사용하는 방식에서는 연산에 주의가 필요하다. 아래의 예를 살펴보자.

위와 같이 고정 소수점으로 나타낸 5.5와 1.5를 곱하면 아래의 결과를 얻을 수 있다. 이 값을 그냥 사용하게되면 우리가 연산의 결과로 기대하는 값과 아주 다른 값이 나온다. 그리고 만약 1.5가 아닌 조금만 더 큰 수를 곱했다면 표현할 비트가 모자라 오버플로우가 발생했을 수도 있다. 따라서 고정 소수점을 사용한 두 수를 곱할 때는 먼저 앞의 수를 (int64) 자료형으로 타입 캐스팅을 진행한 뒤에, 두 수를 곱하고 $ 2^{14} $으로 나누는 연산이 필요하다. 그 결과 아래와 같은 값을 얻을 수 있다.

이렇게 고정 소수점을 다루기 위해서는 오퍼랜드에 따라 연산 방식이 조금씩 다르다. 모든 연산을 전부 다 이렇게 다루기에는 양이 너무 많으니... 연산 테이블만 첨부한다! 참고로 핀토스 문서에 보면 자세하게 나와있으니 그걸 참고해도 좋다.

아래의 표에서 n은 정수, x와 y는 고정 소수점 형태의 실수이다.

이렇게 mlfqs까지 구현을 완료하면 프로젝트 1에서는 다음과 같이 all pass를 받을 수 있다!