프로세스는 무엇일까?+Trace32로 ps명령어 제작

*Trace32는 프로그래머스 Dev코스에서 진행한

'리눅스커널전문가과정'에서 '김동현'소장님께 지원받아 활용했습니다.

그와 동시에,스크립트파일 작성방법에 대한 지원을 받았음을 밝힙니다.

 

 

컴퓨터를 공부하는 사람이라면

'프로세스'에 대한 이야기는 꼭 공부하고 넘어갑니다.

그런데 '프로세스'가 무엇인지 제대로 이야기하기 힘든 경우가 많습니다.

저 역시도 한때는 '개념'으로만 프로세스를 배우고

이것이 어떻게 동작하는지에 대해서는 제대로 몰랐습니다.

하지만 실제적으로 어떻게 컴퓨터에서 돌아가는지 배우고 난 후에는

왜 프로세스를 배우고 어떻게 활용할지를 배웠습니다.

 

프로세스를 왜 알아야할까?

그렇다면 프로세스에 대해서 왜 공부해야할까요?

바로 시스템의 실행흐름을 알기 위해서입니다.

보고계신 그림은 커널의 실행흐름을 출력하는 ftrace 메세지입니다.

리눅스 커널 전문가 과정 과제중에서

'컨텍스트 스위칭이 일어났을 때에 다음에 실행될 프로세스를 설명하세요'

라는 과제가 있었습니다.

프로세스가 어떻게 동작하는지 알기 때문에

sched_switch가 일어나는 후의 next_comm이라는 필드를 보고

'다음에 일어날 프로세스는 Chrome_ChildIOT입니다'라고 말할 수 있습니다.

프로세스의 동작원리와 각각의 필드에 적힌 의미를 파악한다면

차근차근 시스템의 동작을 읽어낼 수 있습니다.

 

 

프로세스란?

프로세스는 시스템 메모리에서 실행중인 프로그램을 의미합니다.

작업관리자를 열어보면 

이렇게 다양한 앱들이 실행되고 있다는게 보입니다.

이 앱들이 바로 프로세스입니다.

user 공간을 기준으로 보면

각각의 프로세스에 따른 메모리가 cpu에 할당이 됩니다.

이 메모리가 독립적으로 각각 할당되고있는거죠.

일부 개념서에서는

'프로세스는 cpu에 올라가있는 프로그램이 자기만 있는줄 안다'

라고 하는 이유도 이 때문입니다.

위에 작업관리자로 돌아가 보겠습니다.

위에 크롬/스타2/카톡/파워포인트

각각의 프로세스가 실행되고 있습니다.

만약 스타2가 카톡에 영향을 주어서 

모든 카톡방에 나가게 된다면 당황스럽겠죠?

이렇듯 프로세스 각각은 서로 독립된 영역에서 독자적으로 수행합니다.

 

프로세스는 어떻게 동작하는걸까?

프로세스는 그러면 어떻게 동작을 하는걸까요?

cpu내부를 간략하게 그려봤습니다.

메모리에 각각의 프로세스들이 저장이 되어있고

cpu core에서는 그 동작들을 수행할 레지스터가 있습니다.

Memory에 있는 프로세스를 cpu core로 로딩시킵니다.

그 후에 cpu core 레지스터는 저장된 값에 따라 동작을 수행합니다.

수행 후의 동작결과를 Memory에 store시킵니다/

https://door-of-tabris.tistory.com/entry/%EC%BB%B4%ED%93%A8%ED%84%B0%EB%8A%94-%EC%BD%94%EB%93%9C%EB%A5%BC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%99%EC%9E%91%ED%95%A0%EA%B9%8C1%ED%8E%B8

레지스터, 왜 알아야하고 어떻게 동작할까?

 

 

그런데 cpu core는 하나에 한 프로세스만을 수행할 수 있습니다.

여기서 그러면 자연스럽게

'그러면 작업관리자에 수 많은 프로세스들은 어떻게 동시에 수행하냐?'라는 말이

자연스럽게 나오게 됩니다.

실질적으로 사용자 입장에서 '동시'에 수행하도록 만드는 것이 바로 context switch입니다.

여러가지 프로세스 동작 각각을 번갈아가면서 수행하는 것을 의미합니다.

위의 작업관리자로 비유하면

스타2실행하고 카톡으로 넘기고

카톡실행하고 T32로 넘기고

T32수행하고 크롬으로 넘기고

이런 과정을 계속 반복한다고 보시면 됩니다.

 

잠깐!오개념 잡기

->멀티프로세스보다 멀티 쓰레드가 더 좋다?

 

'면접대비 cs공부'이런 글이나 영상을 보면

꼭 나오는 개념이 프로세스 vs 쓰레드입니다.

그 중에 멀티프로세스 vs 멀티쓰레드에 대한 부분이 있습니다.

저의 경우에는 오개념이 박혀 잘못된 생각을 했었는데

"쓰레드는 비동기적으로 동작하고 각 쓰레드가 메모리를 공유할 수 있다.

그러니 멀티프로세스보다는 멀티쓰레드로 작업하는 것이 더 효율적이다"

이는 프로세스/쓰레드의 개념을 '글'로만 배운 잘못된 결과입니다.

쓰레드는 프로세스 안에서 동작하는 실행의 단위이기 때문에

한 프로세스 안에서 여러 동작을 수행하고자할때에는 멀티쓰레드가 좋습니다.

하지만 각각의 독립적인 동작을 수행해야한다면 멀티프로세스가 더 좋고요.

예를들면 위의 작업관리자를 기준으로보면

"스타2안에 컨트롤/자원관리/미니맵/경고음 등등을 

스타2라는 하나의  프로세스 안에  멀티쓰레드로 구현한다"

"스타2/카카오톡/ppt/크롬 등등이 각각 독립적으로 사용되게

멀티프로세스로 구현하자"

상황에 따른 쓰임이 다른 부분이지, 언제나 이게 좋다는 건 잘못된 개념입니다.

 

 

 

Process??Task??

 

시스템분야를 공부하신 분들이라면

Task라는 용어도 접하셨을 수 있습니다.

Task는 임베디드 프로젝트에서의 용어로

프로그램을 실행하는 단위를 뜻합니다

현재에는 임베디드 개발자들도 리눅스기반의 프로젝트를 사용하게 되면서

task라는 용어가 시스템 엔지니어링 쪽으로도 유입이 되었습니다.

process task두 용어가 지닌 의미가 겹치는 부분이 많아

현재는 사실상 같은 말이 되었습니다.

그래서 프로세스를 분석할 때에

'테스크 디스크립터'라고 부르게 되면서

프로세스가 어떻게 동작하는지를 파악하고 있습니다.

잘 모르겠다 하시면

'프로세스==테스크'라고 넘기셔도 무방합니다.

 

테스크 디스크립터를 분석하자!

T32로 테스크 디스크립터를 보면

필드가 엄청나게 많이 보입니다.

https://elixir.bootlin.com/linux/v6.1.60/source/include/linux/sched.h

sched.h - include/linux/sched.h - Linux source code (v6.1.60) - Bootlin

커널 소스를 정리한 bootlin에서 해당 페이지를 찾아보면

필드에 대한 설명이 나와있습니다.

그런데, 이 많은 걸 어떻게 다 분석하지?

어떤 걸 위주로 분석해야하지?

이런 생각이 들어 걱정됩니다.

많은 필드가 있지만

아래 소개해드릴 ps명령어 구현에 사용한 필드를 중심으로 

하나씩 소개해드리겠습니다.

 

tasks

가장먼저, 프로세스를 순회할때 사용한 tasks라는 필드입니다.

위에 소개된 테스크 디스크립터의 정보가 담긴 주속밧의

head를 저장합니다.

cmm스크립트를 보시면, 

g_task_struct_list_offset이라는 이름으로

tasks필드가 저장된 주소를 받습니다.

다음 프로세스를 순회할때

global 변수인 g_task_struct_list_next를 통해 다음 주소값을 알아냅니다.

그 후에 next의 주소에 head가 저장된 offset만큼 빼면

테스크디스크립터가 처음부터 저장된 주소를 받을 수 있습니다.

 

comm

프로세스 이름에 대한 정보입니다.

 

 

parent

프로세스 부모에 대한 정보입니다.

프로세스가 생성이 될때

부모프로세스에서 fork를 수행합니다.

이때 부모프로세스의 메모리가 그대로 복사되어 새로운 child를 형성합니다.

부모프로세스 정보를 알 수 있다면

"어떤 프로세스에서 나온건지"알 수 있습니다.

저는 이 필드를 활용해서

'부모 프로세스의 이름'을 출력하도록 스크립트를 작성했습니다.

 

__state

프로세스의 상태를 볼 수 있는 필드입니다.

bootlin에서 state에 관련된 flag정보를 볼 수 있습니다.

주로 Running,INTERRUPTIBLE,STOPPED를 활용합니다.

 

mm

 

프로세스가 user 프로세스인지, kernel 프로세스인지

체크할 수 있는 프로세스입니다.

user 프로세스를 가상공간에 할당한 주소를 의미하므로

위에 처럼 Null이라면 커널 프로세스이고

아래처럼 주소값이 있다면 유저 프로세스입니다.

 

 

pid

프로세스 우선순위를 의미합니다.

 

utime/stime

프로세스 clock시간을 의미합니다.

User space에서 실행한 시간을 Utime

Kernel space에서 실행한 시간을 Stime이라고 합니다.

이 둘을 더하면 CPU time이 나옵니다.

Cpu time은 clock이 얼마나 수행되었는가를 체크하며

프로세스가 얼마나 동작했는지 보여주는 지표입니다.

 

cpu_context

 

Cpu context라는 필드에는 x19부터 pc까지의 레지스터 정보가 담겨져있습니다.

이는 context switching이 일어나기 직전의 레지스터 값들을 담고있으며

이 정보를 통해 레지스터값들이 어떻게 변화했는지를 알 수 있습니다.

 

Trace 32 version ps명령어 구현하기

ps명령어를 실행하면 이렇게 현재 실행되고 있는 프로세스의 정보가 나옵니다.

이를 T32버전으로 구현해봤습니다.

 

ps_custom.cmm

0.01MB

시연 영상입니다.

 

 

도움자료

 

디버깅을 통해 배우는 리눅스 커널의 구조와 원리

시스템 소프트웨어 개발을 위한 Arm 아키택처의 구조와 원리

프로그래머스 Dev 코스 리눅스 커널 전문가 과정

김동현 소장님 및 멘토님들의 피드백