Advanced Size Optimization of the Linux Kernel

Advanced Size Optimization of the Linux Kernel

Tim Bird 

Sony Mobile Communications

Outline 

- 커널 사이즈문제 

bloat의 특성과 그것을 dealing하는 전략

- Automatic reductions

제한을 기반으로 하는 최적화

- 추가적인 커널 사이즈 연구 

- 작은 시스템작업을 위한 자원

커널 사이즈문제

시스템이 더많은 기능을 가질수록 버그수정의 시간이 더 필요해진다.

추상화, 레이어링, 일반화 개념들이 소프트웨어에 추가가 된다.

그런결과 시스템의 많은 소프트웨어들이 실행이 안된다. (사용하지도 않는 기느잉 많다.)

오픈소스의 Bloat

Generalization - 리눅스는 작은 센서부터 대형 서버까지 지원한다.(너무 많은 기능들은 설정가능하다.)

Dealing with bloat

임베디드 디바이스는 특별한 유즈케이스를 가진다.

나의 product의 튿별한 유즈케이스를 위한 re-specialize가 필요하다.

Bloat trajectory  

시간이 지남에 따라 소프트웨어는 생성되고 있다. 

커널의 은 지난 10년동안 10%정도 크기가 커졌다.

manual tuning의 전략을 사용할수 없다. 

2.6.12버젼은 4700개의 config option을 가진다. 그리고 3.9는 13000개의 옵션을 가진다. (너무 많다.)

개개인의 개발자는 이 많고 어려운 옵션들의 전문가가 될수없다. 

그렇기 때문에 자동적인 방법의 reduction이 필요하다.   

유저 스페이스에서 bloat의 문제는 별로 안중요하다 메모리가 필요할때 마다 dmand하기 때문에 그렇게 크게 중요하지않다 하지만 커널의 경우는 항상 메모리에 적제 되어있기 때문에 필요하고 임베디드에서는 swap를지원안하는 경우도 있기 때문에 더 중요하다. ( 가상 메모리를 지원하지 않는다. ) 

Automatic Reduction (Intro)

소프트웨어를 줄이기 위해서 사용하는 코드와 사용하지 않는 코드를 구별하는 것이 필요하다. 

이 연구는 리눅스 커널에서 사용하지 않는 코드를 찾아내고 제거하는 몇가지 서로 다른 기술들을 소개한다.

bloat의 일반화 문제

시스템의 의 고정상태를 알지못한다.(함수에 입력을 아는것에 한계가있다.)

- 사용하지 않는 존재하지않는 하드웨어와 드라이버의 생략은 쉽다. 

- 하지만 에러를 처리하는 루틴은 생략하는 것은 힘들다. (특정 입력이 들어 올때 까지 동작하지않는)  

우리는 커널의 고정된 입력을 식별할수 있을까? 그리고 컴파일러는 코드를 최적화 할수 있을까?

임베디드의 고정적 상태의 예 - uid

uid로 리눅스 커널의 사용자를 식별하는데 만약 root(0)만이 사용하는 임베디드 시스템이라면 setID(사용자를 식별하는 함수)가 필요할까?

Auto-reduce project

커널을 자동적으로 reduce하는 방법을 찾자!

- LTO (Link-time Optimization)

- 시스템콜의 제거

- 커널 커멘드 라인 아큐먼트 제거

- Kernel constraint system ( 커널에 제약 조건 주기 )

발표 마지막에 이중 실제로 실용적으 사용할수 있는건 LTO뿐이다. 이외에 커널의 극한 스패셜라이징 이 답이다. 

LTO (Link-time Optimization)

LTO는 GNU 툴체인의 기능이다. gcc 컴파일의 기능이다. 

컴파일의 Link step에서 시간을 더 들여서 최적의 코드 최적화를 하는 전략이다. 

지금 ARM과 X86용 LTO가 나와있는 상태이다. 관련 논문 

lto.pdf

지금 정리하는 이 발표자료의 저자인 팀버드가 암버젼을 만들었는데 LTO의 장점이라면 성느으이 향상으로 말할수 있다. 

모든 클래스를 완전 새롭게 재 생성하여 최적화 하는 것으로 저자의 세계최초 ARM LTO는 약 6%의 커널 사이즈 절약 효과가 있으며 성능적으로는 각 기능별 약 5~18%의 향상이있다고 말하고 있다. 

 

LTO의 단점은 긴 빌드시간 코드가 커질수로 폭팔적으로 증가한다. 그리고 중복되는 코드 삭제 부분에서 포인트 오류가 발생할 수 있다. 

LTO가 최적화 하는 부분은 read-only 변수를 찾아서 최적화 한다. 

첨조 호출을 직접 호출로 최적화 한다. 함수가 지속적으로 불리는 경우도 최적화가 가능하다 예를 들어 Kmalloc_GFP_Kernel의 경우 메모리 할당이 실패하도 지속적으로 메모리 할당을 시도하는 함수인데 이런경우 최적화가 가능하다고 하다 컴파일의 Link 과정에서 

하지만 자동적으로 코드를 최적화 할 수 있는 방법으로 매우 좋은 방법이고 지속적으로 성장이 필요 Inling함수의 이야기도 나오고있다. 

// 내가 접근하기에는 내 목표인 최소한의 소스 코드 확보와는 다르고 컴파일러 이슈인거 같다.

System Call Elimination 

이 이론은 매우 간단하다. 

- 유저 스페이스의 에서 사용되는 시스템콜의 종류를 찾아 낸다.

- 커널의 사용되지않는 시스템콜을 삭제한다. 

몇가지 주의 사항을 고려하면서 시행하기만 하면된다.

사용/미사용 시스템콜 찾기 

최종 싱클 바이너리 바일은 통해서 알아 낼수 있다. (오브젝트 파일의 어셈코드에서 시스템콜 코드를 찾아 낸다.

find-syscalls.py 라는 파이썬 프로그래을 사용할수도 있다. (오브젝트 파일에서 시스템콜 리스트를 만들어준다.)

라이브러리 문제도 있는데 라이브러에서 시스템 콜을 사용하기 때문에 사용하지 않는 라이브러리 를 제거 하는것도 필요하다. Libopt 라는 프로그램도 있다. 

// 고려 한다.

Kernel Command-line Argument Elimination

이거 해봤자 효과가 엉청 미비하다. 6KB 정도 최적화 가능했다고 한다 저자가 시도 하였을때는 

Kernel Constraint System 

- 목표는 소프트웨어를 최적화하기 위해 시스템 전체에 적용할 수 있는 제약 조건을 찾는 것이다.

이전에 설명했던 uid에 한 제약조건을 주는 것으로 직접 소스에 수정이 필요한 부분이다. 저자가 실행한 결과 

304Byte를 아낄수 있었는데 이것은 미비한 결과이고 리죽스의 구조체가 서로 첨조하는 부분이 매우 복잡해서 제약조건을 주는것도 힘든과정이다. 저자가 이러한 방법은 지금 리눅스 환경에서는 실패한 방법이라고 말하고 있다.

Additional Reseach

저자가 찾아낸 흥미로운 대학에서 연구되고 있는 연구로 University of Gent 와 University of Arizona 에서 진행하고 있다.

- Link-time re-writing 

어셈코드를 추출하여 분석한다. 

찾아낸다 공통된 instruction sequences를 

전체 프로그램 그래프 수준에서 코드의 분석이 가능해야한다.

특별한 기능으로 첨조 함수도 찾는다. 

큰문제가 있는데 첨조 포인트 문제를 가지고 있다.

- Cold-code compression 

난 이게 흥미 로웠다. 잘 사용되지 않는 코드를 압축해서 가지고 있다 예를 들어 오류 처리 루틴같은건 압축해서 코드를 가지고 있다 사용할때 풀어서 사용한다는 개념이다. 가상 메모리를 사용하지 않는 환경에서 적용 

Conclusions

저자가 말하는 결론은 결국 쓸만한건 

- LTO

- Aggressive specialization 

이 두가 뿐이 없는다는데 내가 시도 해볼껀 일단은 공격적인 최적화를 해서 내가 주무를 수 있는 최소화된 코드를 획득 하는것이 중요하다고 생각한다. (그 1단계로 elce11 의 Darren Hartd의 tuning embedded Linux의 내용을 기반으로 진행한다.)

Bird-Kernel-Size-Optimization-LCJ-2013.pdf