Linux Kernel(4.14) Hacks

rousalome.egloos.com

포토로그 Kernel Crash




[라즈베리파이] 워크큐(Workqueue)는 왜 잘 알아야 할까? [라즈베리파이] 워크큐

이번에 워크큐는 왜 잘 알아야 하는지 생각해 봅시다.
워크큐는 영어 문법으로 보면 BE 동사와 같다고 볼 수 있습니다. 리눅스 커널을 탑재한 어느 시스템에서도 워크, 워커 쓰레드를 볼 수 있습니다. 리눅스 핵심 함수들에서 워크큐를 쓰고 있기 때문입니다. 다른 기법과 마찬가지로 워크큐 함수를 모르면 드라이버 코드를 읽을 수 없습니다.

워크를 써서 후반부 처리를 하는 코드를 작성하기는 쉽습니다. 하지만 워크를 쓰다가 생기는 문제는 개발자가 직접 해결해야 합니다. 워크큐 커널 함수 입장에서는 누가 워크를 큐잉했는지 모릅니다. 그래서 커널 핵심함수나 드라이버에서 워크를 큐잉해도 워크큐 커널 함수는 동등하게 처리합니다. 워크를 쓰다 생기는 문제를 해결하려면 어떤 단계를 밟아야 할까요? 우선 우선 커널이 워크큐를 어떻게 처리하는지 큰 동작 흐름을 그리면서 차근차근 분석을 해야 합니다. 어느 코드부터 분석을 시작할지 알고 있어야 분석을 진행할 수 있습니다.

마지막으로 워크큐를 잘 활용하면 유연하게 드라이버를 설계할 수 있습니다. 각 디바이스 드라이버마다 다양한 시나리오가 있습니다. 만약 특정 디바이스에 정해진 값을 쓰고 적절한 시간 이후에 제대로 값이 써졌는데 이를 확인하는 시나리오를 생각해 봅시다. 특정 디바이스에 정해진 값을 쓰는 동작은 워크로 구현하고 딜레이 워크를 활용해서 다시 확인할 수 있습니다. 그래서 디바이스 드라이버 초기화 코드를 보면 워크와 딜레이 워크를 여러 개 선언해서 코드를 여러 조각으로 나눠서 설계합니다.

주위 리눅스 드라이버 개발자들은 워크큐가 아주 쉽다고 말하는데 어떤 분은 너무 어렵다고 합니다. 이렇게 서로 다른 답을 하는 이유는 무엇일까요?

워크큐를 대중적으로 많이 쓰지만 리눅스 커널 레벨에서 워크큐가 어떤 원리로 구현됐는지 확인하는 분은 많지 않습니다. 워크큐 함수만 써서 커널 후반부 처리를 구현한 개발자는 워크큐가 쉽다고 하고 커널 워크큐 코드 분석에 도전하다가 실패한 분은 워크큐가 어렵다고 하는 겁니다. 워크큐 분석이 어려운 가장 큰 이유는 워크큐 자료구조를 익히기 어렵기 때문입니다. per-cpu 타입 변수의 개념과 링크드 리스트를 활용해서 워크 자료 구조를와 데이터를 어떻게 처리하는지 알아야 합니다. 하지만 자료구조만 정확하게 머릿 속으로 그리면서 코드를 분석하면 워크큐 동작은 그리 어렵지 않게 이해할 수 있습니다. 

워크큐 자료구조 관련 코드를 만나면 워크큐 자료 구조 전체 흐름을 그림과 함께머릿속으로 전체 구조를 그리면서 코드 분석을 할 필요가 있습니다.





핑백

덧글

댓글 입력 영역