Memory Failure Report throuth MCE Apr 9, 2009

http://lkml.org/lkml/2009/4/7/368

Intel의 앞으로 나올 CPU에 background로 memory를 check하여 error를 report해주는 기능이 들어간다고 Andi는 전하고 있다.
Report는 기존의 x86 specific한 Machine Check Exception을 그대로 사용할 것이며, MCE register를 통해 error가 발생한 물리 주소를 얻을 수 있게 된다.

그러므로 OS가 이 기능을 적절히 활용하기 위해서 Andi는 하드웨어가 나오기전 먼저 Linux OS에 대해서 상기 기능을 어떻게 활용할 것인지에 대해 RFC를 내놓았다.

Andi가 이번 패치에서 주 target으로 정한 것은 KVM이다. Host에서 error정보를 전달 받아 그 내용을 KVM guest들에게 전달하기 위한 설비이다. 하지만 이 기능은 KVM에 종속되지 않으며 얼마든지 다른 응용 프로그램들도 사용할 수 있도록 generic하게 설계되었다.

정보를 알리는 방식은 새로운 signal을 사용하는 방식이며, error가 발생한 page의 특성에 따라 다르게 동작한다.

1. slab page
2. reserved page
3. page cache clean page
4. page cache dirty page
5. unknown page
6. free page
7. swap clean page
8. swap dirty page
9. anonymous page
10. unevictable page
11. huge page
12.compound page

하지만 현재는 RFC단계로 위의 모든 type에 대해 구현되어 있지 않은 상태이다.

이 패치의 tricky한 part는 다른 VM 사용자들의 page에 대해 비동기적으로 접근하게 된다는 점이다. 그것은 page 동기화에 대한 rule을 해치는 일이 될 수 있기 때문에 매우 조심해야 한다. Andi가 이 패치에 대해 제일 걱정하는 부분이 바로 이 부분이다. 리눅스 커널의 page관련 lock 처리는 매우 골치아픈 부분이다.

현재, mainline에서 이 패치의 기능에 대해서는 모두 수긍하는 편이며 구현 또한 RFC 단계 치고는 상당히 깖끔하다. 앞으로 남은 주제는 아직 구현되어 있지 않은 page type에 대해 어떻게 처리할 것인가와 함께 비동기적인 page에 대한 접근에서 발생할 수 있는 문제에 대한 coverage등이 될 것으로 보인다.

이 패치는 하드웨어적으로 아직 들어가 있지 않은 구현에 대한 검증을 위해서 소프트웨어적으로 프로세스의 page를 poisoning할 수 있는 별도의 test 기능까지 구현되어 있다.

꼬랑지)
이 패치를 보면 Andi가 속한 Intel의 Open Source Lab이 무엇을 하는지 잘 알 수 있다.
아직 시장에 나오지 않은 기능에 대해 OS community에 선행 학습을 시키며 앞으로 나올 자신들의 하드웨어의 판매전략을 위해 기존 OS에 미리 기능을 구현해 놓겠다는 것인데..

아직까지도 하드웨어에만 목을 매는 우리나라의 몇몇 기업들의 우둔한 전략에 대해 할말이 너무나도 많지만..