20190220

오늘의 일기
* Thermal throttling이 되지 않는 문제를 겪고 있었는데, Quartz repository를 확인해보니 Skylake에서부터 지원이 잘 되지 않는 것처럼 보인다 (창현이 형이 이야기한 것처럼). 따라서 Skylake 이전의 프로세서를 사용하는 2-socket machine을 찾으면 thermal throttling을 사용할 수 있을 것이다.
* 김정한 연구원님께서 Quartz Broadwell support 패치를 공유해주셨다 🙂 감사합니다!
* Quartz를 사용하다 발견한 것. CPU scaling governor의 기본값이 powersave라는 점이고, maximum frequency로 실행되도록 하려면 performance로 설정해야한다는 것이다. 이전에 B가 내 실험 결과를 보고 CPU frequency가 이상하게 낮은 것 같다고 이야기한 적이 있었는데, 아마도 governor를 performance 모드로 두고 실험했었어야 하는 것이 아닌가 하는 생각이 들었다. 그렇게 해야 조금 더 안정적인 실험 결과를 얻을 수 있지 않을까 하는 생각도 들었다.

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

조금 더 읽다보니, turbo boost도 끄는 것이 안정적인 성능 측정에 좋은 것 같다.
* Quartz는 어플리케이션 수준에서 memory latency, bandwidth emulation을 해주므로 내가 연구하는 목적(global or per-socket slowdown)에 직접 적용할 수는 없었다. 하지만 bandwidth throttling의 경우에는 원리가 동일하므로 global 적용에 사용할 수 있을 것 같다. 그리고 무엇보다도 bandwdith throttling이 동작함을 확인했다. Broadwell에서 thermal throttling의 offset은 0x108인데, Quartz의 경우에는 0x190을 사용함을 확인했다. Quartz는 thermal throttling이 아닌, power throttling을 사용하기 때문이다.

broadwell-thermal-throttling.png

broadwell-power-throttling.png

다음은 내 실험 머신에서의 bandwidth_model 측정값 (Xeon CPU E5-2630 v4).

read    32783   613.980925
read    32798   1331.933782
read    32813   1667.680295
read    32828   2244.707063
read    32843   2830.731351
read    32858   3401.403713
read    32873   3987.751026
read    32888   4563.409295
read    32903   5118.522179
read    32918   5680.464841
read    32933   6246.204578
read    32948   6792.415065
read    32963   7336.296947
read    32978   7873.636593
read    32993   8444.040868
read    33008   8972.147179
read    33023   9506.513054
read    33038   10050.956465
read    33053   10589.369220
read    33068   11150.146306
read    33083   11666.827625
read    33098   12219.822388
read    33113   12746.824314
read    33128   13300.188716
read    33143   13818.806441
read    33158   14355.950756
read    33173   14902.858298
read    33188   15459.023100
read    33203   16009.564095
read    33218   16527.525580
read    33233   17079.827723
read    33248   17650.644131
read    33263   18189.736887
read    33278   18716.773338
read    33293   19297.937401
read    33308   19879.784459
read    33323   20444.334603
read    33338   20958.102270
read    33353   21542.293564
read    33368   22053.483976
read    33383   22540.922715
read    33398   22940.812944
read    33413   23309.009608
read    33428   23542.588664
read    33443   23725.678945
read    33458   23792.787457
read    33473   23847.649883
read    33488   23867.505521
read    33503   23936.853923
read    33518   23888.309116
read    33533   23913.470971
read    33548   23933.355766
read    33563   23911.053279
read    33578   23946.225795
read    33593   23871.598804

* Compiling!
compiling.png

연구 주제에 따라 다르겠지만, 시뮬레이션을 주로 하는 아키텍쳐 연구실의 특성 상 시뮬레이션 또는 빌드하며 busy-waiting하는 경우가 종종 있는 것 같다. Busy-waiting하며 낭비하는 시간만 줄여도 졸업을 1-2년은 빨리할 수 있을 것이라고 생각한다. 첫째로는 busy-waiting하는 시간에 다른 일을 함으로써 얻는 이득이 있고, 둘째로는 생각없이 짠 코드 또는 무의미한 실험의 비효율성을 해결함으로써 얻는 이득이 있다. Critical path 상에 없는 motivational 결과를 뽑아본다거나, 관련 연구를 찾아본다거나, 다음 단계에 해야 할 작업을 미리 하는 등, 생각해보면 할 수 있는 일이 참 많다. 실험 또는 구현이 비효율적이라 critical path를 늘리고 있다면 조금 더 효율화할 수 있는 방안을 생각해봐야 한다. 시뮬레이터가 메모리를 너무 많이 사용하는 것은 아닌지? (비효율적인 코딩), 시뮬레이터가 너무 오래 실행되는 것은 아닌지? 더 나은 평가 방법이 있는지?

Advertisements
Posted in 1) Memo

20190219

오늘의 일기
* 회사에서 느꼈던 것 중에 하나는 일상 보고 능력의 중요성이다. 학교에서는 교수님 또는 학생들과 가깝게 비형식적으로 대화하며 연구에 대해 이야기하지만, 회사에서는 조금은 더 형식적으로 보고하는 경우가 잦다. 그 때문에 J는 내게 이메일을 작성할 때에도 핵심을 간결하게 표현하도록 강조했었다. 오늘 같이 일하는 친구가 상사 L에게 답변하는 것을 보고 다시 한 번 보고 능력에 대해 생각해보는 기회를 가질 수 있었다. 상사 L이 “우리 시스템에는 A밖에 사용하지 못하는 것처럼 보이는데, 그게 맞는지 조금 더 자세한 내용을 확인해볼래?”라며 메일을 보냈었다. 가장 먼저 떠오른 대답은 “사용 가능합니다”였고, 그 이상이 잘 떠오르지 않아 막막했다. 다행히도 같이 일하는 친구 Y가 이에 대해 메일을 작성해 보냈고, 내가 생각할 수 있는 이상의 것을 체계적으로 정리해서 이메일로 답장했다. 가장 먼저 A를 사용할 수 있는지에 대해 대답하고, 언제 해당 제품이 시장에서 구입 가능할 것인지, 내부 아키텍쳐와 프로토콜의 특징은 어떻게 되는지 (간략히), 우리 연구 내용을 해당 제품에 적용하려면 어떠한 변경점과 어려움이 있는지에 대해 작성해 보내주었다. 다음에 내가 답변할 일이 있을 때 잊지 않기 위해 기록을 남긴다.
* -momit-lock-prefix 옵션을 사용하면 lock prefix 없이 빌드 가능함.
* B라는 친구가 나와 Y가 생각지도 못한 방식으로 기술적 문제를 해결하는 방법을 제시함. 동작할지는 모르겠지만, 그 방향으로 솔루션을 제안했다는 점에서 놀라웠다. 이곳의 친구들은 늘 나를 놀라게 하는 것들을 보여준다.

Posted in 1) Memo

20190217

오늘의 일기
* Thermal throttling을 적용하려 하는데, 잘 되지 않아 찾아보니 숨겨진 extended PCI configuration space의 경우에는 접근이 불가능할 수 있다고 한다. BIOS 수준에서 지원해주어야만 한다고 함 (링크 1, 링크 2).

Posted in 1) Memo

20190216

오늘의 일기
* 구현한 baseline이 잘 돌아가지 않아서 당황했는데, baseline으로 삼은 논문 자체가 잘못되었을 수 있다는 생각이 들었다. 같은 현상도 관점에 따라서 한없이 부정적이거나 긍정적으로 볼 수 있는 것 같다.
* 전체 실험 결과가 이상하다는 점에서도 당황했는데, 특징적인 워크로드를 잡아서 가정을 세우고 실험을 한다면 괜찮을 것 같다는 생각을 했다. 그렇다면 실험 결과 분석도 쉽고, 실험 시간도 훨씬 짧게 가져갈 수 있다. 처음부터 general case를 풀기보다는 specific case를 풀어 아이디어 또는 구현의 올바름을 확인한다.

Posted in 1) Memo

20190214

오늘의 일기
* Data caching의 결과값에 대한 설명 링크

Posted in 1) Memo

20190211

오늘의 일기
* 훈련소에서 공자 말씀이 있는 책을 읽었는데, 정확히 내용은 기억이 나지 않지만 ‘어디에 살 것인지 결정하는 것이 중요하다’라는 문구가 있었던 것 같다. 본인이 어떻게 살고자 하는 의지도 중요하지만, 그러한 의지가 꺾이지 않도록 하는 환경에 스스로를 가져가는 것이 어쩌면 더 중요할지도 모른다.

Posted in 1) Memo

20190209

오늘의 일기
* Cache and TLB Flushing Under Linux
* Soft lockup 디버깅시에 panic을 일으키는 방법이 있다고 함. https://www.kernel.org/doc/Documentation/lockup-watchdogs.txt
* 모든 메시지를 시리얼 포트로 출력

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 ignore_loglevel"
Posted in 1) Memo
Recent Posts
누적 방문자 수
  • 152,489 hits