Arm Linux Kernel Hacks

Arm 아키텍처는 캐시를 제어하는 명령어를 제공하는데, 명령어의 동작 원리를 제대로 파악하려면 Arm 아키텍처에서 정의된 캐시의 동작과 관련된 용어를 알아야 합니다. 먼저 캐시와 관련된 용어를 소개하고 캐시를 제어하는 명령어를 소개합니다.


실전 개발에서 캐시의 동작을 설명할 때 '캐시 플러시(Cache Flush)'란 용어를 많이 씁니다. 일반적으로 캐시의 데이터를 메인 메모리에 내린다는 의미로 사용됩니다. 리눅스 커널이나 RTOS에서 Arm 프로세서의 캐시를 제어하는 함수나 레이블의 이름에 flush가 포함된 경우가 많습니다. 일반적으로 캐시 플러시는 캐시 라인에 있는 데이터를 메인 메모리에 복사해 캐시와 메인 메모리에 있는 데이터의 싱크를 맞추는 동작을 뜻합니다. 

그런데 Arm 아키텍처 문서를 보면 Flush라는 용어 대신 다음과 같은 용어를 사용해 캐시의 동작을 설명합니다.  

 * 캐시 클린
 * 캐시 Invalidate
 * 캐시 Clean & Invalidate

위에서 명시된 용어에 대해 더 자세히 알아봅시다.  

캐시 클린

캐시 클린은 현재 레벨의 캐시 라인을 다음 레벨의 캐시나 메모리에 기록하는 동작입니다. 예를 들어 데이터 캐시를 클린한다고 하면 캐시 라인 중에 Dirty(더티)로 명시된 캐시 라인을 다음 레벨의 캐시나 메모리에 써주는 동작입니다. 예를 들어 L1 캐시를 클린하면 L1 캐시에 더티로 마킹된 캐시 라인을 L2 캐시에 써줍니다.

캐시 Invalidate

Invalidate는 캐시 라인의 데이터를 비우는 동작입니다. 처음 부팅할 때 캐시 라인의 상태로 돌아간다고 볼 수 있습니다. 그렇다면 캐시 라인의 데이터를 어떻게 비울까요? 캐시 라인의 Valid 비트를 클리어하면서 Invalidate를 수행합니다. 

캐시를 Invalidate하는 동작은 언제 수행할까요? 한 가지 예시를 들어 보겠습니다. 트러스트존 아키텍처에서는 논시큐어 상태에서 시큐어 상태로 자주 바뀌는데, 시큐어 상태에서 실행됐던 캐시 라인의 데이터는 Invalidate한 다음에 논시큐어 상태로 이동합니다. 시큐어 상태에서 실행된 데이터가 캐시 라인에 남아 있으면 보안 상 취약점으로 남게 됩니다.

캐시 Clean & Invalidate

캐시 Invalidate를 수행하는데 더티(변경) 상태로 마킹돼 있는 캐시 라인이 있으면 데이터의 불일치가 발생합니다. 그래서 Invalidate를 할 때 더티(변경) 상태로 마킹돼 있는 캐시 라인이 있으면 해당 캐시를 클린한 다음에 Invalidate를 수행합니다. 이 동작을 'Clean & Invalidate'으로 명시합니다.

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

컴퓨터가 발명된 후 초장기 시점에 컴퓨터는 어떤 모습일까요? 컴퓨터의 크기는 방 하나 정도였습니다. 그 당시에 CPU와 메인 메모리만 존재했습니다. CPU가 어떤 명령어를 실행하거나 데이터를 가져오려면 메인 메모리에 접근했습니다. 

컴퓨터 기술이 발전하면서 컴퓨터의 성능을 키우려는 시도를 합니다. 처음에 CPU의 처리 속도(클럭)를 키우려는 방향으로 다양한 연구를 진행했는데 CPU의 성능을 최대로 키우면 이에 비례해 시스템의 성능도 함께 좋아질 것이라 예상했습니다. 그래서 CPU의 성능을 측정했는데 다음과 같은 흥미로운 사실을 알게 됐습니다.

    "CPU의 대부분 시간은 메인 메모리에 접근하는데 허비한다."

CPU의 실행 속도는 매우 빠른데 메모리에 접근하는 시간은 CPU의 실행 시간에 비해 상당히 느리다는 사실을 알게 됐습니다. 차가 속도를 냈다가 신호등에서 기다렸다를 반복하듯이 CPU가 실행하다가 메모리에 접근해 데이터를 가져오기 위해 기다리면서 많은 사이클을 낭비했습니다. 이를 병목 현상이라고도 부릅니다.

성능을 측정한 다음에 병목 현상을 최소화하는 방법을 고민을 한 끝에 다음과 같은 아이디어가 떠올랐습니다.

    "CPU 사이에 속도가 빠른 임시 메모리가 있으면 속도가 빨라질 것이다."

CPU 근처에 속도가 성능이 매우 좋은 메모리를 위치시켰더니 성능이 상당히 개선된 것을 확인했습니다. 이처럼 CPU와 메인 메모리 사이에 있는 고속 메모리를 CPU 캐시라고 합니다.

다음 그림을 보면서 캐시의 기본 개념을 배워 봅시다. 



그림 17.1 프로세서 내부에서 캐시의 위치

그림의 가장 왼쪽 부분에 CPU, 가운데는 고속으로 동작하는 캐시 그리고 가장 오른쪽에 용량이 큰 메모리가 있습니다. 

CPU가 자주 사용하는 데이터를 캐시가 갖고 있으면 CPU는 캐시에 있는 데이터를 로딩하므로 속도가 빠를 것입니다. 대신 CPU에서 메모리에 직접 접근하면 시간이 오래 걸립니다. 그래서 CPU는 메인 메모리에 접근하기 전에 먼저 캐시에 데이터가 있는지 체크합니다. 만약 CPU가 사용할 데이터가 캐시에 100% 있다면 CPU는 기분이 좋을 겁니다. 용량이 크면서 속도가 빠르다는 느낌을 받을 겁니다. 그런데 이게 정말 가능할까요? 만약 CPU가 처리할 데이터나 명령어가 캐시에 항상 존재한다면 가능합니다.

그렇다면 CPU가 사용할 데이터가 캐시에 항상 존재할까요? 그렇지는 않습니다. CPU가 사용하는 모든 데이터가 100% 캐시에 존재하지 않습니다. 만약 캐시에 찾으려는 데이터가 없으면 메인 메모리로 가서 데이터를 가져와야 합니다.

[정보] 캐시와 성능

사실 캐시가 CPU 옆에 달려있는 작지만 동작 속도가 빠른 메모리라고 여기는 분도 있습니다. 하지만 캐시를 어떻게 설정하느냐에 따라 시스템 성능에 지대한 영향을 끼칩니다. 그래서 시스템 소프트웨어 개발자는 Arm 프로세서에서 캐시가 어떤 방식으로 구성돼 있는지 잘 알 필요가 있습니다.

  
Cortex-A53이나 Cortex-A57과 같은 프로세서의 세부 스팩 문서를 보면 프로세서의 세부 구현 방식을 확인할 수 있습니다. 이 중에 캐시의 타입과 캐시의 사이즈를 확인할 수 있습니다.

다음 표는 Arm 프로세서 별로 사용되는 캐시의 타입과 사이즈입니다.



표 17.1 Arm 프로세서 별 캐시 사이즈
---
[정보] 캐시 표현 방식

많은 CPU 아키텍처 문서에서 캐시를 $로 표기합니다. I$은 명령어(Instruction) 캐시, D$는 데이터(Data) 캐시를 뜻합니다.

표 17.1과 같이 Arm 프로세서마다 캐시를 다른 방식으로 구현합니다. 한 걸음 나아가 SoC 칩셋 업체들이 캐시의 사이즈는 적절히 변경해 자신의 칩에 맞게 디자인할 수 있습니다. 사실 CPU 캐시 이외에도 Arm 프로세서에서 사용되는 캐시의 종류는 생각보다 많습니다. Write 버퍼, TLB 캐시, predict 캐시를 예로 들 수 있습니다.
---

CPU가 메모리 주소에 존재하는 데이터를 로딩하는 과정에서 어떤 단계를 거칠까요? CPU는 먼저 캐시에 접근해 찾으려는 데이터가 있는지 체크합니다. 만약 캐시에 데이터가 있으면 캐시에 존재하는 데이터를 가져옵니다. 이 과정에서 메인 메모리에 접근하지 않습니다. 메인 메모리에 접근하면 수십에서 수 백 사이클을 허비하기 때문입니다. 이는 80km로 달리다가 신호등을 만나 기다리는 상황과 비슷합니다.

되도록 CPU가 캐시에 존재하는 데이터만 사용하고 메인 메모리에 접근하지 않으면 성능은 좋아질 겁니다.
---
[정보] 캐시는 어떻게 구성돼 있을까?

캐시는 어떻게 구성돼 있을까요? 캐시 메모리와 캐시 콘트롤러로 구성돼 있습니다. 

캐시 콘트롤러는 메인 메모리에 존재하는 데이터를 알아서 캐시 메모리에 로딩하는 역할을 합니다. 캐시 메모리는 말 그대로 캐시 데이터를 저장하는 공간입니다. 캐시 콘트롤러 CPU가 사용할 것 같은 데이터를 예측해 캐시 메모리에 로딩합니다. 
---.

여기까지 캐시의 기본 동작 원리를 알아봤습니다. 이어서 Arm 프로세서에 적용되는 멀티 레벨 캐시 구조를 알아봅시다.

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>