'메모리관리'에 해당되는 글 3건

  1. 2017.01.29 :: [LWN] The future of the page cache
  2. 2012.10.21 :: [LWN] Adding a Huge Zero Page
  3. 2010.09.29 :: OOM Killer 동작 과정에 대한 간단한 설명
Skills/Linuxworld 2017. 1. 29. 22:01

이번 기사는 올해 열린 linux.conf.au 2017 의 발표 중 페이지 캐쉬의 미래에 대한 기사.
(유료컨텐츠..1주일 후 공개 열람 가능)

https://lwn.net/Articles/712467/

대규모의 persistent memory 에 대한 보장을 위해서는 많은 부분의 변화가 요구되었었고,
커널에 대한 페이지 캐쉬 기능이 계속 필요로 하는 부분인지에 대한
의문이 제기되었다고 한다.

----

무튼 기자 Corbet 의 윌콕스에 대한 감정은 썩 좋지 않은 것 같은 뉘앙스였지만,
페이지캐쉬와 그 동작에 대해서 상당히 많은 이해를 주는 기사 및 발표였다고 생각한다.

"코딩상의 문제라면... 알아서 해결하면 되겠네 ㅎㅎㅎㅎ"

posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2012. 10. 21. 05:11

기사 원문 : http://lwn.net/Articles/517465


이건 이달 초에 발간된 위클리 매거진에 실려있는 기사인데, 이미 공개된거라 여기에 쓸까말까


고민하다가, 어차피 남들이 보는것도 좋지만, 사실 내 공부가 더 중요하기 때문에 블로깅하는것이므로,


부끄럼없이 다뤄보기로 하겠다.. 물론 Transparent Huge Pages 를 먼저 다뤄야 좋겠지만,


이건 조금 더 복잡한 내용이 필요하므로 그 Huge Page 의 성능적 이슈를 해결하기 위해 나온,


Huge Zero Page 컨셉에 대해서 먼저 간략하게 알아볼 것이다.



코멘트들을 보면 재밌는게, KVM 같은 HugeTLB 를 사용하는 환경에서 HZP 로 인한 잇점과,


벤치마킹이나 PoC 등 몇몇 프로세스 테스팅등에서, HZP 로 인해 프로그램 코드의


특별한 수정 없이 퍼포먼스에 큰 향상을 볼 수 있었다는 얘기도 있다는거..

내 생각에도 이 Huge Zero Page 는


특히나 가상화 및 대용량 In-memory DB 의 발전을 위해서라도 반드시 사용되어져야 하는


기능이지 않을까 싶다..


솔직히 HZP 를 얘기하기 전에 우선 Zero Page 에 대한 더 상세한 설명과,


또한 Transparent Huge Page 나 TLB 에 대한 상세 설명이 필요하긴 했으나,


내 생각에는 늦은 커널 공부에는 작은기능부터 거꾸로 올라나가서, 왜 이 기능이 나타나게되었고,


이 기능들을 필요로한 핵심 매카니즘이 어떤건지에 대해서 거슬러 올라가는것이,


그나마 가장 나은 방법이라고 생각하기 때문에, HZP 에 대해서만 얘기해 보았다.


PS. Transparent HugePages 에 대한 것은 2011 년에 이미 Corbet 에 의해, 커널문서로

작성되어있고, 관련된 파라메터들도 잘 설명되어 있다...

기회가 되면 이것에 대한 실제 벤치마킹등을 이용한 테스트도 포스트 해보고 싶다.


PS2. 아마 다음포스팅은 정말로 HugeTLB 에 대한 글이 되야 할것 같다.

회사 Product 도 연관된 부분들이 많아서 ( 특히 Middleware 나 DB )


PS3. 사실 부족한 이해력으로 LWN 기사만 보고 즉석테스트 정도로만 해서 정리한 글이므로,

언제든지 잘못 이해한 부분이 있으면 지적질 좀 해주라고.. 제발..


기사 원문 : http://lwn.net/Articles/517465




posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2010. 9. 29. 20:13
병가받고 한달 뽀지게 쉬는중인데 중간중간 대전같은데 끌려가서 일하고 있느라,

나름 또 바빠버려서 정말 관심있는 커널 MM 에 대한 공부가 중단되었었다..

정리하는 셈 치고, 또한 최근 P 모사에서 OOM killer 가 동작되버려 kdump 조차 안된 상황(?)을 보니,

급 급해져서 살짜쿵 내용좀 정리해 본다...

사실 올 초반부터 OOM killer 의 성능을 향상시키기 위한 수 많은 토의가 있었다..

시작은 fork-bomb 를 검색하는 것에서 시작하였으나, 용자 'David' 의 주도로 인해,

반지원정대 못지않은 큰 여정이 되어버렸다...

AndrewDavid 의 패치를 검토하고, 또 싸우기도 많이 하면서 결국 2010-6-11 자로

패치를 적용시킨다... 이 패치에 대한 스토리와 내용은 너무 길고 길어서 여기서 단순간에 쓰기엔 어려우니

다음으로 미루도록 하고, 다시 말하지만, 내가 나름대로 연구해본 OOM killer 의 동작 과정에 대해 보기로 한다.

코드를 설명해야 하는 것을 최대한 배재하려고 하나, 나역시 프로그래머라고는 할 수 없는

시스템엔지니어일 뿐이기에, 좀 꼬일수도 있을것 같다... 대충 보자.. 쿨럭


위와 같은 함수와 동작 원리를 알고 이제 깊이 파다보면, background reclaim, direct reclaim 등이 있고,

reclaim 중에서는 또 write back 등 I/O 관련되는 것들이 주루룩 나오고,

그 전에 일단 커널 메모리 매핑이나 vm 매핑........ 엄청 쏟아진다... 머리 깨지며,

한달 동안 이것만 붙잡고 밥안먹으면서 살아도 모르겠다 ㅠㅠ

아참 참고로, 6월 적용된 패치로 인해 앞으로의 커널에서의 움킬러의 동작 방식.

즉, 메모리 reclaim 등에 대한 일부 부분들은 바뀌게 되었으니 참조로만 알아두길 바란다.

PS. 사실 내가 공부하면서 이해하고 있는 부분을 재정리 한 글이기때문에 부족함이 많을 수도 있다..

가르침 주실 분들은 언제든지 가르침 주시길 희망함 :)

스프링노트에 다시 좀 정리해서 플로우별로 정리했다...

http://mirr.springnote.com/pages/6484805

posted by mirr

댓글을 달아 주세요