Open1ヶ月前にコメント追加3

VAIO type PにGentoo Linuxを入れて遊ぶまで

Gitリポジトリに使ったコードなどはまとめてあります。

最後まで動作確認していないコードが9割なのでもし利用する際は事前に検証してください。

 crossdev最初はカーネルのクロスコンパイルをする予定だったが、途中で脱線してcrossdev遊びに。
手順は公式Wikiの通りに進めれば良い。

もしかしたらEmbedded Handbookも役に立つかも。
この段階でUSEやgccのチューニングを行えるらしい。

とりあえず、動かなかったら緩くしようの精神で、-Ofast -march=bonnell -mtune=intel -mssse3 -mfpmath=sse -fomit-frame-pointer -flto  -fexcess-precision=fastを設定した。

Gentooのインストールが終わり次第、ここら辺のチューニングはしていきたい所。
同じCPUの世代なので、ここら辺の値はVAIO P Seriesでも変わらないと思われる。
crossdevで作ったデータは/usr/i686-unknown-linux-gnu/var/cache/binpkgs/ディレクトリをそのままWebサーバにぶん投げて、binrepos.confにURLを記載してあげればAtom Z520でビルドする苦行は回避できそう。

JenkinsとDockerでここら辺を完全自動化してもいいかも。
ただし、現状なぜか@systemでgccがビルドできなかったりするので、とりあえずStage3ができるようになってから考える。

 CatalystStageファイルを作ってくれるらしい。crossdevと同時進行で試していたので、両方でgccをビルドし始めたりと結構辛いことになった。

先にCatalystでStage 1とStage 3を作り、その後Stage 3をcrossdevの環境に持って行くと良さそう。

ただし、Catalyst自体はmake.confを受け取る（Wiki通りに進めると/var/tmp/catalyst/config/stages/make.confにできる）が、ここに設定したCFLAGS等を使ってくれているのかは不明。
もし途中でUSEを変えろと言われたら、/var/tmp/catalyst/tmp/23.0-openrc/stage1-bonnell-openrc-@Timestamp@/etc/portage/内のpackage.use等を良い感じに修正する。
Stage3の作成でなぜかPythonのエラーが出てきているので、少し脱線してカーネルビルドをする。

 カーネルのクロスコンパイル基本的には、公式WikiのCross compiling the Kernelを読んで進めた。

資料にはARCH変数はi386を使うように書いてあるが、どうやら最近はx86で良いらしい。
xkmake defconfigをするとx86_64_defconfigを持ってくるので、arch/x86/configs/i386_defconfigをcpで持ってきた。

このコンフィグはさすがにうまく動いてくれる。
コンフィグの編集はいろいろと考えているものの、欲しい機能を削減した状態のうまく動くコンフィグはできていない。

何か弄るとCaps LockとScroll Lockが点滅してカーネルパニックになるため、ここで踏ん張っていろいろ書くしかないかなと。
また、現状なぜか、can't open /dev/tty2: No such file or directoryのエラーがtty2-4に対して１秒おきくらいに出てくるので、これもトラブルシューティングしなければ。
とりあえず、BusyBoxが動いてくれたのでカーネルビルドの目処が立って良かった。

 弄っても問題無かったカーネルパラメータProcessor type and features
Processor family -> Intel Atom

Device Drivers
Multifunction device drivers
Intel SCH LPC -> *



 弄ったら動かなくなったカーネルパラメータDevice Drivers
Graphics support
Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
Intel GMA500/600/3600/3650 KMS Framebuffer -> *



GMA500のドライバーが何をしているのかがいまいち分からないが、フォーラムを見る限り重要そうなので、何とか動かせるようにしたい。モジュールなら良いのかは未検証。

 調べ物系軽量化にあたり、いろいろと調べてみた内容をまとめてみる。

 muslとgnu (glibc)フットプリントが小さい物がmuslらしい。ただ、対応ソフトに違いが出そう。

メモリ2GのVAIO type Pはmuslが良さそうだが、とりあえずはglibcで進めていった方が良いかもしれない。

 g++とClangColfax Internationalの記事にg++ 7.2.0とClang 5.0.0の比較が載っていた。
コンパイルしたバイナリの処理のスループットはg++のほうが良くなるらしい。

ベストはIntel C++とのことだが、Intel C++はディスコンして今はLLVMベースのIntel oneAPI C++ Compilerになっているらしく、GentooのemergeにIntel C++を使わせる手法もあまりメジャーなものではないことから、今回は採用を見送った。

mkaraki

 Catalystの進捗WSLではなく、Gentooを実機に入れて動かしたところ、問題無くStage3ができあがった。

エラーはPython関係なので、WSLは関係無いように思うが、なぜなのだろうか･･･
とりあえず、この段階で、公式のインストールメディアと最低限最適化をしたStage 3ができあがっているため、公式が提供するi686のStage 3よりかはパフォーマンス的に良い状態でインストールはできそう。

ただし、ビルドですさまじい時間が取られそうなので、実機へのインストールはcrossdevが成功してからかな。

 crossdevcrossdevも同じように実機で試してみた。ただし、Stage3を流用する方法で行ったが、ROOTがおかしいとのエラーが出た。Stage3を流用したからなのか、実機だとうまくいかないパターンなのかは要検証。
正直、crossdevはなんとしてでもDockerでやって内部サーバにbinpkgをCI/CDしたいところ。

mkaraki

crossdevあたりを一度置いておいて、バイナリの最適化を少し調べてみた。

Crear LinuxなりCachyOSで行われていたようなLTO, PGO, BOLTを使ってみるのは良さそう。
ただ、元があのCPUなので、どれくらいまともに使えるかは微妙。FirefoxとThunderbirdがサクサク動いてくれるとうれしい。最悪ThunderbirdはGraph API対応メーラを作ってしまえば（HTMLメールの閲覧を除いて）そんなに大変なことにはならないが、ブラウザが無いのは困る。
BOLTはLLVMが要求されるようで、最初のコメントに乗せたベンチマークを無視してLLVMにするメリットがあるのかを考えた方がよさそう。そもそもGentooのWikiに載ってなさそうなので問題も起きそうだし。
後は、Intel oneAPI DPC++ CompilerにもBOLT対応がありそうなので（少なくともGitHubのリポジトリにはあった）、純粋なLLVMの代わりにこっちを使った方が良いのかも調べたい所。
良い感じにバイナリの実行速度を比較するコードがあるとうれしいのだけれども…