기존 이솝 임베디드 포럼의 지식인 서비스가 게시판 형태로 변경되었습니다.
안녕하세요 안드로이드 플랫폼을 기반으로 연구를 하고있는 대학원생입니다.
제가 개발하려고 하는 것은 안드로이드 백그라운드에서 CPU-GPU 에관해 전력 최적화를 하는 프로그램을 개발하는 것입니다.
(CPU, GPU frequency를 조절하여)
surfacefliger 처럼 백그라운드에서 동작하도록 개발을 하고싶습니다.
이와 관련하여 안드로이드에대해 공부를 하고있는데 내용이 방대하고 초심자라 방향을 잡기 쉽지않습니다.
여러가지 궁금한 점들이 많은데 해결되지 않는 질문들이 있습니다.
1. service에서 system resource(CPU, GPU frequency 등)을 제어 가능한가요?
- 현재까지 linux 어플리케이션상에서 procfs, sysfs를 통해 조절이 되는것 까지는 확인하였습니다.
2. 제가 하려고 하는것이 service 개발이 맞는가?
- NDK, PDK 같은 개발환경이 많은데 정확한 개념이 잡히지 않습니다.
어떤 방향으로 공부를 해야할지 잘 모르겠습니다...
많은 고수분들의 답변 부탁드립니다.
이 외에도 많은 조언 부탁드립니다.
감사합니다.
안녕하세요 답변 정말 감사드립니다.
제 질문이 많이 모호했습니다.
조금더 연구내용을 덧붙이자면 3D 게임을 타겟으로 Performance - Energy 간의 trade-off를 고려한 DVFS policy를 만드는 것입니다. 최종적인 목적지는 커널 레벨에 DVFS governor를 구현하는 것입니다. 허나 제 실력이 부족하기도 하고 아직 막연한 부분이 많아 커널 레벨보다 상위 레벨에서 검증을 한 후 커널 레벨로 내려가려고 하고있습니다.
추가로 이를 위해서 FPS를 측정해 데이터화하여 제가 구현하려는 서비스(또는 커널)에 데이터를 전달해주어야 하는데 안드로이드에서는 Binder를 이용한다는 것을 알았습니다. 아직 공부가 부족하여 실제적으로 어떻게 데이터를 주고받아야할지 모르는 상태입니다. 이때 FPS를 Surfaceflinger에서 frame을 update해주는 함수의 호출 횟수로 FPS를 측정하려고 하는데, 이 때문에 네이티브 서비스쪽에서 구현을 하면 상대적으로 수월하지 않을까라고 생각했습니다.
실례가 안된다면 겟페우스님께서 무슨일을 하시는지 알려주실수 있나요? 제 연구 방향에 대해서도 여러가지 조언을 듣고싶습니다.
감사합니다
불가능합니다.
겟페우스 님 말대로 일반적으올 PM(DVFS)는 Kernel PM에서 관리합니다.
간단하게 load를 보고 DVFS를 합니다.
김석원씨가 그 구조를 빠삭하게 아시나요?
또 Vendor별로(삼성포함) Android HAL단에서 Kernel에 DVFS 를 요청하는 경우가 많습니다.
(Android가 HAL단을 통해 OS에게 요청합니다.)
일반적올 CPU, GPU둘다 자체적으로 load를 측정해서 DVFS를 합니다.
CPU와 GPU는 서로 다른 방법으로 load를 계산해서 DVFS를 합니다.
삼성것은 DEVFREQ이라고 또 자체적으로 Memory쪽과 IP에 대해서도 DVFS를 합니다.
각각은 또 서로 연결되어 있고 영향을 줍니다.
또 load에 따라 CPU를 On/Off합니다.
HMP 스케줄러와도 연동이 됩니다.
또 Thermal에 따라 DVFS를 제약합니다.
이 모든것은 해당 코드를 잘알지 못하면 건들수 없고, 개인이 혼자서 할수 없습니다~~
수고하세요
예전에 말씀하신 것과 비슷한 프로젝트를 진행한 적이 있습니다.
1. 커널의 스케쥴러 등을 수정했었습니다.
2. 안드로이드 power manager service를 손 댔었던 기억도 좀 납니다만, user define scheduler를 손대기는 쉽지 않았습니다.
3. 해서 ndk로 직접 제어를 하는 구조를 만들어 썼었습니다.
가장 중요한 것은 정책과 해당 CPU에 관련된 부분을 명확히 알아야 합니다.
다만, 이런 부분은 칩벤더가 정보를 잘 안푸는 경우가 많습니다.
대신 도전해 보시면 꽤 많은 것을 얻을 수 있다라고 생각합니다.
근래 저도 계속 애먹고 있는 부분이 이 부분입니다.
예전 자료를 찾아봐서 드릴 수 있는 부분이 있으면 드리도록 하겠습니다.
커널 코드를 mainline것을 그대로 가져다 쓰지 않고, vendor에서 배포하는 kernel code를 사용하면
아마도 CPU/GPU/DEVFREQ/THERMAL이 서로 엮여서 동작할것입니다.
-> 각 코드는 해당 제품에 최적화 되어 있기 때문에 PLATFORM이 번경되면 최적화된 부분이 틀어지게 됩니다.
또 GPU도 자체적으로 load를 계산해서 DVFS를 하는데, 순수 GPU부분만 확인하기 어렵습니다.
또 User(Platform)에서 Frequency를 설정하려면 governor를 Userspace governor로 변경해야 하는데, 이렇게 되면
또 최적화된 부분이 틀어지게 됩니다.
생각할게 많습니다.
CPU 쪽은 앵그리님이 말씀하신대로 이미 kernel 내에 userspace governor 라는 것이 있기 때문에 기존 system에서 사용하는 governor를 disable 하고,
userspace governor를 enable 하면 Android service 단에서 sysfs node를 통해 frequency control이 가능합니다.
물론 해당 sysfs node를 Android service가 접근 가능하도록 permisiion 등은 조정해 주셔야 합니다.
연구하시고자 하는 부분이 소모전류 최적화 부분이니 기존의 vendor가 최적화한 governor의 틀을 굳이 가져갈 필요는 없겠죠..^^
다만 CPU는 kernel 내에 CPUFreq이라는 표준화된 framework이 존재하지만, GPU의 경우는 DVFS를 위한 별도의 표준 framework이 kernel 내에 존재하지 않기 때문에
chip vender 별로 GPU frequency를 control 하는 방법이 모두 다르고, sysfs 쪽으로 나와있는 외부 interface도 모두 다를 겁니다.
GPU 쪽도 chip vender별로 DVFS를 하는 방법이 모두 다르기 때문에, 결국에는 GPU 쪽은 기존 코드를 분석해서 원하는 입맛에 맞게 수정하는 작업이 필요할텐데 쉽지는 않은 작업일 듯 합니다.
그리고 대부분의 경우 CPU/GPU는 kernel 내에서 최적화를 하는 경우가 대부분이고, 일부 coner case 최적화를 위해 별도의 Android service를 두고 보정하는 방향으로 최적화 됩니다.
전 안드로이드 코드 구조를 전혀 모르지만 제 개인적 생각에서 답변 드리겠습니다.
안드로이드 PM은 전부 리눅스 커널이 관리하고 안드로이드는 전혀 관계 없지 않나요? 어느정도 전력 프로필을 조절 하는것은 가능할수 있을진 모르겠는데 코딩의 여지는 전혀 없는것 같습니다.
커널의 PM코드도 근데 커널 버전이 조금 낮거나 장치가 최신이면 함수만 만들어놓고 알맹이가 없는 경우도 종종 봐서 제대로 관리를 하는지도 의문이네요. 대기업 삼성의 엑시노스 PM도 단순히 init이라는 함수를 불렀다가 종료할때 해방하는 간단한 구조인 경우가 많았습니다.(한참 걸려서 패치 되었습니다.) 특히 GPU의 전력 관리는 사실상 거의 불가능하다고 봐야 맞지 않나 싶네요. GPU의 작업이 언제 끝나는지에 대한 예측 방법도/보장도 없고 코드도 10만행이 넘는 경우가 많은 관계로... 괜히 건드리면 전부 병목으로 변신하지 않나 싶네요.
일단 전력 프로필을 변경 하면 장치가 저전력 모드가 되는 것을 보면 프로필을 선택하는 정도는 할수 있을듯 한데 이걸로 연구다운 연구가 가능한지는 상당히 의문입니다. 안드로이드면 완전 최상위 레이어인데 API를 이용하는 레이어에서 전력 관리를 하는 서비스를 만들어봤습니다. 라는 연구는 들어 본적이 없습니다. 일단 Contribution 으로서 안드로이드 용 서비스 입니다 라고 말하는 순간 가치가 제로입니다. 아마도 분야에 따라 다르겠으나, 시스템 소프트웨어 학회에선 어디를 막론하고 Accept하는 일은 없을거라 생각합니다. 본래 전력 관리 관련 연구는 기본적으로 범용성도 있는 좀 더 낮은 레이어(커널 레벨)까지 내려와서 하지 않나 싶다는게 제 개인적 생각 입니다. 어느 논문인지 이름까진 기억 나지 않으나,(아마 Eurosys 아니면 OSDI라고 기억 합니다) 전력 관리 코드를 어디에 넣어야 하는지를 자동으로 추천 해주는 기능과, 커널이 수정 되어져 있는 경우 자동으로 power domain을 슬립 시켜 주는 내용이 적힌 연구를 본 기억이 있습니다. 이쪽이 아마 가깝지 않나 하는 생각이 드네요.
https://engineering.purdue.edu/~xzl/papers/asplos15.pdf
이것도 꽤 비슷한 연구 같고요.
기본적으로 이런 연구는, 부하의 경향을 예측 하여 어떻게 파워도메인을 가장 길게 잠자는 상태로 유지 할 수 있는지가 관건이 되는데, 그 레이어가 API레이어까지 올라오는 순간 그걸 제어 하는것 자체가 보장되지 않습니다. 이런 의미에서 굳이 안드로이드 레이어까지 올라와서 절력관리를 시도 하시려는 의도가 잘 와 닿지 않아서 제대로 된 답변을 못해 드리겠습니다.
퍼포먼스따위 어차피 느리면 사용자가 기다리는거, Greedy한 어프로치로 해도 상관 없어. 반응 좀 느리면 어때 어차피 전화긴데. 라는 생각의 절전 이라면 지금도 이미 안드로이드가 다 관리 해주고 있지 않나 싶고(배터리 잔량으로) 좀 더 예측에 기반한 전력 관리를 하려면 절대적으로 커널 레이어로 내려가야만 이야기가 될 것이라는 생각이 무조건적으로 드네요.
실력이 없어서 제대로 된 답변은 못해드렸습니다.