Android PDK Build with ZRAM

지난번 글이 너무 길어지기도 했고, 72GB의 ZRAM으로도 Build Fail이 났기에, Tuning컨셉으로 좀더 접근해보는 글로 새로 작성해봅니다.

Plain text
Copy to clipboard
Open code in new window
EnlighterJS 3 Syntax Highlighter
mnt/zram/out/dist/logs/build_progress.pb.tmp: no space left on device<br>[ 90% 151467/168049] //tools/metalava:metalava kotlinc [linux_glibc common]<br>FAILED: /mnt/zram/out/soong/.intermediates/tools/metalava/metalava/linux_glibc_c<br>ommon/kotlin/metalava.jar /mnt/zram/out/soong/.intermediates/tools/metalava/meta<br>lava/linux_glibc_common/kotlin_headers/metalava.jar
...
failed to build some targets (47:50 (mm:ss))
mnt/zram/out/dist/logs/build_progress.pb.tmp: no space left on device<br>[ 90% 151467/168049] //tools/metalava:metalava kotlinc [linux_glibc common]<br>FAILED: /mnt/zram/out/soong/.intermediates/tools/metalava/metalava/linux_glibc_c<br>ommon/kotlin/metalava.jar /mnt/zram/out/soong/.intermediates/tools/metalava/meta<br>lava/linux_glibc_common/kotlin_headers/metalava.jar ... failed to build some targets (47:50 (mm:ss))
mnt/zram/out/dist/logs/build_progress.pb.tmp: no space left on device<br>[ 90% 151467/168049] //tools/metalava:metalava kotlinc [linux_glibc common]<br>FAILED: /mnt/zram/out/soong/.intermediates/tools/metalava/metalava/linux_glibc_c<br>ommon/kotlin/metalava.jar /mnt/zram/out/soong/.intermediates/tools/metalava/meta<br>lava/linux_glibc_common/kotlin_headers/metalava.jar
...
failed to build some targets (47:50 (mm:ss))

조금만 더 가면 될 듯도 한데, 해서 80GB 크기를 늘려서 다시 시도해봅니다. 81920이 되겠네요. 그전에 이전참고하였던 블로그에서 사용했던, OUT_DIR_COMMON_BASE도 살짝 실험해보고 넘어갑니다. 이걸로 세팅을 하니 OUT_DIR가 살짝 다르게 나오긴하네요. 빌드는 잘 되려나 모르겠습니다. 아직 72GB ZRAM인 상태입니다.

$ export OUT_DIR_COMMON_BASE=/mnt/zram/out

이러면 OUT_DIR이 /mnt/zram/out/AOSP 로 잡히네요. AOSP가 현재 Android PLATFORM 소스코드가 놓인 Root이긴 합니다. 정확히 원하는건 Soong/.interediates 들의 OBJ/Executable만 ZRAM에 나머지 image generation등 후처리 과정은 SSD에서 되면 좋겠는데 말이죠. 그래서 또 /build/* 를 뒤적거려봅니다.

일단 OUT_DIR_COMMON_BASE도 별 다를것 없이 90%에서 용량 부족으로 멈추네요. 앞서 뒤적거리다가 DIST_DIR을 따로 봅니다. 한번 OUT_DIR대신 DIST_DIR을 설정하는 것으로 바꿔봅니다. 원하는 것과 정 반대면 참… 그렇네요. 그래도 두가지를 모두 조합하면 또 달라질것 같기도 하니 두가지 다 해봅니다. 우선 DIST_DIR만 ZRAM으로 지정하고 시도합니다. 근데 지금 dist보니 750M정도 되어 있던데.. 흠. 효과가 있을런지… 역시 45%가 지나도록. 507M밖에 안썼네요… 이건 아무래도 망한듯 합니다.

다시 인터넷을 좀더 뒤져보고, 알고리즘을 바꿔볼까 생각이 듭니다. lz4hc 가 준수해보이네요.. 물론. 빌드 하고 있는데 압축하는데 CPU를 얼마나 잡아 먹을지는 또 변수가 되겠습니다.
https://segmentfault.com/a/1190000041578292/en

자기전에 고전적인 방법인 symbolic link한번 걸어서 (out/soong만 ->zram쪽으로 교체)시도해보고 안되면 overlayfs 로 넘어가도 보려합니다. 아직은 72G에 lzo-rle 알고리즘인 상태입니다. 안되네요. . 방향을 바꿔서 압축 알고리즘 바꾸고 72G로 시도합니다.

$ zramctl –reset /mnt/zram0
왜 아예 디바이스가 날아가는지는 모르겠지만, 그래서 다시 서비스 스타트

$ systemctl start zram-config.service

Set up a zram device:
zramctl [-f | zramdev] [-s size] [-t number] [-a algorithm]

$ echo “lz4hc” > /sys/block/zram0/comp_algorithm

를 하면 될 것 같지만, /dev/zram0 가 영 안살아 나서..


게시됨

카테고리

작성자

태그: