지난 1월 3일 언론에 해당 내용을 공개하면서 어마어마한 인텔의 치명적 하드웨어 결함이 전세계에 충격을 안겨줬었다.
이미 잘 따뜻하게 입고있는 외투를 졸지에 뺏긴듯 한 상대적 박탈감을 줄 수 밖에 없었다.
벌써 커널쪽에서 대두되고 있는 여러가지 극복방안 등에 대해서 LWN 에 기사가 올라오기 시작한다.
1. KAISER/KPTI
- 결과적으로 커널의 주소를 User space 에서 완전히 분리했다.
이는 사실 최근 커널인 4.1X 대의 Window 에서만 적용이 그나마 수월할 만큼
기존 x86 Architecture 에 대한 OS logic 을 상당히 뒤엎는 부분이기 때문에 아직 다른 window 에는 머지되지 않고 있는 것으로 보인다.
LWN 의 Jake 에 의하면 4.4 나 4.9 이하에서는 적용하기 어려울 수도 있다고 설명하고 있다.
Kernel space 정보를 담고 있는 테이블을 분리했기 때문에, 그만큼 더 많은 계산이 필요하고,
추가적인 Cost 가 들어갈 수 밖에 없지만, Linus 에 의하면 이는 Intel 이 초래한 어쩔 수 없는 당연한 결과이며,
OS/Software level 에서 처리할 수 있는 방법은 쉽게 나오지 않을거라고 하고 있다.
2. I/O 성능 정하로 인한 새로운 I/O CB polling Interface 추가
요거 조금 흥미로운 편인데, KAISER/KPTI 로 인해 IRQ interrupt 에 대한 system call 처리
즉, IRQ Interrupt cycle 에 대한 비용이 증가하는 것이 실질적인 성능저하의 원인인데,
그걸 위해 Non-Blocking poilling 에 사용되는 기존의 select(),
poll(), epoll_wait() 외에
AIO 를 이용한 IOCB_CMD_POLL 인터페이스가 1월 4일 Christoph Hellwig 에 의해 제안되었다.
원래 AIO 는 동기화를 시키지 않고 I/O 를 처리하는 것이기 때문에, 자연스럽게 Polling 을 통한 I/O 상태 체크의 기능이 들어갈 수 밖에 없었는데,
일반 I/O 에 대해서도 IO control block 에서 I/O event 를 대기시킬 수 있는 Queue 를 생성하여 I/O 에 대한 완료 여부를 Polling 형태로 체크하고
실제 기록이 가능할 경우 다시 단일화된 Submit 을 수행하는 방법을 이용하면
동기화의 비용을 자연스럽게 병렬적으로 진행할 수 있다는 아이디어이다.
Oneshot 형태로 동작하면 큰 문제도 없고
실제로 KPTI 적용 시스템에서 16퍼센트 정도의 I/O 향상을 확인했다고 한다.
즉, I/O request 에 대한 AIO 형태의 대기열을 만들고,
그 대기열로 부터 I/O 준비가 되었는지만 확인하는 Polling 이벤트를 발생하여 장치의 상태가 변경되었을 때 알람을 해주는 형태를 이용하면 AIO 뿐만 아니라,
동기화가 필요한 I/O 에서도 불필요한 Interrupt 및 계산을 줄일 수 있다는 것이다.
이를 위해서는 두가지 상태확인을 위한 Operation 만 추가되면 된다고 하였으나, 아직 논의중이라고 하며, 이글을 작성한 Jonathan 은 10퍼센트의 향상이라 할 지라도 필요하기 때문에 적용되는 것에 긍정적인 평가를 하고 있다.
3. Open Processor
- 인텔이 워낙 똥을 기똥차게 싸 놓은 바람에..
게다가 사실 인텔 뿐 아닌 ARM/AMD 등 x86 기반의 프로세스 모두 결함을 갖고 있는게 드러났기 때문에,
예전에 잠깐 올라오다가 깊숙히 가라앉았던 Open Hardware 붐이
다시 일어날 때 아닌가 하며 Jonathan 은 그에 대한 글을 작성했다.
어떤 소프트웨어적 커버를 통해 발전을 해도, 하드웨어 레벨에서 똥을 싸면 속수무책이라는 말로 시작하고 있으며,
CPU 에서 실행되는 가장 형편없는 취약 시스템인 Intel CPU management 엔진 등을
예로 들며 오픈소스 소프트웨어와 같이 오픈소스 하드웨어도 시작되야 한다고 이야기 시작한다.
오픈 프로세서라는 것은 사실 새로운 경험이 아니다.
Power Architecture 에 대한 오픈프로젝트인
OpenPower, Solaris T1/T2 에 대한 Architecture 공개로 시작된 OpenSPARC,
RISC 에 대한 설계를 공개한 OpenRISC 등을 이야기 하고 있는데,
OpenPower 의 경우 High-end 에 속하고, OpenSparc 은 오라클이가 버려서 무의미하다고 하고, RISC 의 경우 가장 완벽하지 않나 싶다고 의견을 보이고 있다.
특히 OpenRisc 의 경우 임베디드 용으로 타겟이 되어 있는 만큼 상당한 완벽성을 갖고 있으며,
최근에는 RISC-V 라는 보다 더 넓은 범위의 Open CPU 로 발전되었다고 소개하고 있다.
우리가 잘 아는 Western Digital 에서는 이 RISC-V 를 채택할 예정이라고 발표했다고 한다.
물론 Open Processor 를 제작하기 위한 시설을 구하고 사용하는 것은
단순히 'make' 를 타이핑하는 만큼 간단한 비용이 아니지만, 그
렇게 어려운 일은 아닐거라고 설명하며 필자는 글을 마무리 하고 있다.
리눅스가이들에게 던져져 상당히 재밌는 상황이라고 할 수 있을 것 같다.