[조성수] 프로젝트 회고

[ppiyakk2]

프로젝트 목표

• 리눅스 커널 코드를 분석하는 방법을 익힌다.
• 리눅스 커널에 Contribution 하는 과정을 익힌다.
• perf 툴 코드의 동작 방법에 대해 분석하고, contribution 포인트를 찾아 패치를 만든다.
• 리눅스 커널 코드를 분석하고 공헌을 하고 싶은 초심자를 위한 Contribution 가이드 문서를 만든다.

프로젝트 최종 성과물

• 패치 1건 : https://lkml.org/lkml/2016/9/29/668
• Contribution 가이드 문서 1건 : 초보자를 위한 linux perf contribution 가이드 #153

프로젝트 진행 내용

1. perf diff 패치 1건

- 문제

perf diff 는 두 개의 성능 측정 결과를 비교하여, 성능의 차이를 알려주는 명령어이다. 아래 그림은 패치 전 diff 결과이다.

결과를 보면 퍼센트값에 따라 색이 다르게 표시되는 것을 볼 수 있다. diff 결과에서 색을 나누는 기준은 아래와 같다.

• High Overhead : Red
• Mid Overhead : Green
• low Overhead : Normal

즉, Overhead 의 정도에 따라 색을 구분하고 있다. diff 결과의 delta 부분은 이전 데이터에 비해 지금 데이터의 성능 결과가 어떤 차이를 가지느냐를 나타낸다. 양수로 나오면 성능이 더 나빠진 것이고, 음수로 나오면 성능이 향상된 것이다.

즉, delta 는 Overhead 의 정도를 나타내는 것이 아니라, Overhead 의 차이를 나타낸다. 하지만 delta 를 출력하는 색을 결정하는 기준은 Overhead 정도에 따라 색을 구분하는 정책을 따라가고 있다.

따라서, 출력결과를 이해하는데 사용자로 하여금 모호함을 없애기 위해 delta 를 출력하는 새로운 색 기준을 제시하였다.

- 개선 사항

delta 를 출력하는 새로운 색 기준을 아래와 같이 제시하였고, 그에 맞는 패치를 작성하였다.

• 오버헤드 증가 : background red
• 오버헤드 감소 : Blue
• 결과가 동일 : normal

패치를 적용한 후, perf diff 를 실행한 결과는 다음과 같다. 이전에 비해 delta 에 대해서 좀 더 직관적으로 나타남을 확인할 수 있다.

## 2. 초보자를 위한 Linux Perf Contribution 가이드 문서

1주일동안 익힌 perf 코드 분석 방법, 패치 생성, 메일링 리스트에 패치 전송 방법 등을 총 정리하여 초보자도 쉽게 따라하면서 Contribution 할 수 있는 가이드 문서를 제작하였다.

가이드 문서는 아래와 같은 목차를 가진다.

• 1. 개발환경 구축
  • linux kernel 코드 다운로드
  • 의존 라이브러리 설치
  • 컴파일 해보기
• 2. 개발 시작하기
  • 어떤 것부터 시작하는 것이 좋은가?
  • ctags 로 코드 분석 환경 만들기
  • 코드의 탄생 과정 추적하기
• 3. 패치 보내기
  • commit 메세지 작성하기
  • patch 파일 만들기
  • 메일링 리스트에 보내기

3. bugzilla 에 올라온 버그 조사

https://bugzilla.kernel.org는 리눅스 커널에서 발견된 버그를 리포팅하는 사이트이다. 맨 처음 perf 의 실행 과정에 대한 코드 분석이 완료된 이후, contribution 할 내용을 찾기 위해 가장 먼저 시도한 것은 리눅스 커널에 보고된 버그를 살펴보고, 그 중 내가 할 수 있는 내용을 찾아서 패치를 작성해보는 것이였다.

https://bugzilla.kernel.org 에 들어가서 Browse 탭으로 들어가면 아래와 같이 리눅스 커널에서 관리하는 다양한 기능이 카테고리별로 정리되어있다.

우리 팀이 진행하는 프로젝트는 perf 이고 이것은 "Tracing/Profiling" 카테고리에 속한다. Tracing/Profiling 에서 Perf Tool Component 로 들어가면 다음과 같이 perf tool 에 대해서 올라온 버그 목록을 확인할 수 있다.

리포트된 버그가 실제로 수정이 되었는지는 직접 commit log 를 통해서 확인해야했기에 가장 최근에 리포트 된 버그를 선택하여 프로젝트 github 의 이슈로 등록하여 버그 패치를 진행하려 했지만, 현상 재현이 어려워 이 버그를 해결하지는 못했다.

- bugzilla 에 등록된 버그 링크 : [https://bugzilla.kernel.org/show_bug.cgi?id=156121](https://bugzilla.kernel.org/show_bug.cgi?id=156121) ## 4. perf config 옵션 유효성 검증 루틴 개선 제안

perf config 는 system 설정파일과 user 설정파일 두 가지를 지원한다.

• System Config: /etc/perfconfig
• User Config : $HOME/.perfconfig

- 문제 제기

perf config 로 설정파일을 확인할 경우 system 설정과 user 설정을 동시에 사용하도록 지정할 수 없다.

nexusz99@nxz-icns:~/Downloads/perf$ ./perf config --system --user
Error: only one config file at a time

 Usage: perf config [<file-option>] [options]

        --user            use user config file
        --system          use system config file

system 과 user 옵션을 perf 에 등록하고, 동시에 사용했는지 검사 및 에러를 출력하는 코드는 아래와 같다.

OPT_BOOLEAN(0, "system", &use_system_config, "use system config file"),
OPT_BOOLEAN(0, "user", &use_user_config, "use user config file"),

if (use_system_config && use_user_config) {
        pr_err("Error: only one config file at a time\n");
        parse_options_usage(config_usage, config_options, "user", 0);
        parse_options_usage(NULL, config_options, "system", 0);
        return -1;
}

이 부분에 대한 코드를 if 문을 사용하지 않고, OPT_BOOLEAN_FLAG 의 PARSE_OPT_EXCLUSIVE 옵션을 이용하여 mutual exclusivity 를 검사하도록 개선하는 패치를 제안하였다.

• 패치 PR : perf config: Improvement the check routine of mutual exclusivity using between system and user config #134

- 결과

PR 에서 많은 논의가 이루어졌지만, 정책상의 문제이고 미래에 추가될 옵션들과의 조합을 생각해보면 if 를 이용하여 조합을 정하는 것이 맞다는 판단이 들어서 이 패치를 적용하지 않기로 결정하였다.

마무리

• 리눅스 커널에서 제공하는 툴에서 옵션을 처리하는 방법에 대해 알 수 있었다.
• ctags 를 이용하여 터미널 상에서 코드를 좀 더 쉽게 분석할 수 있는 환경을 구축하는 방법에 대해 알게 되었다.
• 리눅스 커널에 패치를 보내기 위해 commit 메세지 작성부터, 패치 파일 생성까지 어디서 배울 수 없는 고급 git 기술에 대해 알 수 있었다.
• 운이 좋게 패치를 작성하여 메일링 리스트에 보낼 수 있었다. 하지만 Maintainer 와 메일을 주고 받으며 논의하고 패치가 반영되는 과정까지 경험하지 못해 매우 아쉽다.
• 처음 리눅스 커널을 접하는 사람끼리 모여서 함께 코드를 분석하고 그 과정을 공유하면서 더 빨리 학습할 수 있었고, 서로에게 힘이 되어주어 좋은 결과를 내지 않았나 생각한다.