アカウント名:
パスワード:
なんでしないの
断片化が悪いとは言ってるけど、速度低下を防ぐ技術=デフラグしてるよ!とは言ってないと思うけど。
てかAndroidを怪しいアプリ以外でデフラグする方法ってあるの?
まずそもそもAndroidというか、LinuxにはHugeTLB FSというものがあってだな。ユーザは容易くHuge pageを扱うことができるし、例えばPostgreSQLなんかは起動時にhugetlbfsが使用可能ならそこ使うようになってる。自分がどんだけメモリ使う気なのかは、自分が一番良くわかってるだろうから、これから自分がするのに必要な分だけを適切な空間に確保せよ、というのがLinus教の教え。
しかし初めはチョロっとしか使う予定がなかったのに、気がついたらこんなに使ってましたなんてことは稀によくある。そういう際にカーネルが良きに図らってくれる機能がTransparent Hugepage Support。こやつがMemory compactionとPage migrationを使い分けながら勝手にHugepageに変換する。
この過程で勝手にデフラグされるので、我々が余計なことをする必要性は全くない。危険が危ない怪しげなアプリ類も全く不要。心配ならCMAやzpool、zbud、zsmalloc、お好みでKSMとzswap、更にidle page tracking対応のカスタムカーネルを焼き焼きしとけば、メモリ管理、及びデフラグが捗ることは捗る。Galaxy厨がよくする「カスタムROMまで行かずともカスタムカーネル焼いただけでキビキビ動く」とかいう都市伝説の正体はそれ。(勿論、BFS & BFQ等へのスケジューラ変更による効果も多少はある。)
ただしLinus教においては、メモリを確保する時はニコニコ顔で貸し付けてくれるものの、借りたメモリを返さなかったどころか実際に許される量を越えてアクセスしようとすると、その瞬間にOOM killerさんが取り立てっつーか、マジで殺しに来るので注意。OOM Killerさんの取り立てに身分の差は全く関係なく、例えそれがkhugepagedやkcompactdやsystemdであっても、OOM Killerさんの気が済むまで無差別に鏖。OOM killerさんの取り立ての仕方があまりにも厳しすぎるので、最近はOOM reaperさんが頑張って仲介してくれてるが焼け石に水な上に、Androidで普通に使われてるようなカーネルバージョンではそもそも存在してない。
つまり要するにあれだ、メモリの連続性よりも空きメモリの方を心配しとけってこった。 >>>>デフラグ厨
お前は Huge じゃなくて Hage だろう……。
えーっと、HugeTLB / Memory compaction / Page migration って、RAMの断片化には関係してるけど、内蔵ストレージの断片化とは何の関係もないでしょ?もしかして高度なギャグかなにか?
長すぎて読む気が起きない、すごいな
よく見ろ、これは吉野屋のコピペだ
# 違う
HugeTLBってソフトページフォルトを削減するだけだから、余り極端な高速化にはつながらない上に高速化出来るケースが限定される技術だったと思うのだけど。
そもそもストレージの断片化と仮想メモリの断片化は全く別物……HugeTLBが実装上ファイルシステムを使っているって程度か。
メーカー側ならアンドロイドに手を入れればいいだろ
バカは自分をバカだと理解できないところが最大の問題。
断片化が悪いって言ってるの?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
デフラグすりゃいいじゃん (スコア:0)
なんでしないの
Re: (スコア:0)
Re:デフラグすりゃいいじゃん (スコア:0)
断片化が悪いとは言ってるけど、
速度低下を防ぐ技術=デフラグしてるよ!とは言ってないと思うけど。
てかAndroidを怪しいアプリ以外でデフラグする方法ってあるの?
Re:デフラグすりゃいいじゃん (スコア:1)
てかAndroidを怪しいアプリ以外でデフラグする方法ってあるの?
まずそもそもAndroidというか、LinuxにはHugeTLB FSというものがあってだな。
ユーザは容易くHuge pageを扱うことができるし、例えばPostgreSQLなんかは起動時にhugetlbfsが使用可能ならそこ使うようになってる。
自分がどんだけメモリ使う気なのかは、自分が一番良くわかってるだろうから、これから自分がするのに必要な分だけを適切な空間に確保せよ、というのがLinus教の教え。
しかし初めはチョロっとしか使う予定がなかったのに、気がついたらこんなに使ってましたなんてことは稀によくある。
そういう際にカーネルが良きに図らってくれる機能がTransparent Hugepage Support。
こやつがMemory compactionとPage migrationを使い分けながら勝手にHugepageに変換する。
この過程で勝手にデフラグされるので、我々が余計なことをする必要性は全くない。危険が危ない怪しげなアプリ類も全く不要。
心配ならCMAやzpool、zbud、zsmalloc、お好みでKSMとzswap、更にidle page tracking対応のカスタムカーネルを焼き焼きしとけば、メモリ管理、及びデフラグが捗ることは捗る。
Galaxy厨がよくする「カスタムROMまで行かずともカスタムカーネル焼いただけでキビキビ動く」とかいう都市伝説の正体はそれ。
(勿論、BFS & BFQ等へのスケジューラ変更による効果も多少はある。)
ただしLinus教においては、メモリを確保する時はニコニコ顔で貸し付けてくれるものの、借りたメモリを返さなかったどころか実際に許される量を越えてアクセスしようとすると、その瞬間にOOM killerさんが取り立てっつーか、マジで殺しに来るので注意。
OOM Killerさんの取り立てに身分の差は全く関係なく、例えそれがkhugepagedやkcompactdやsystemdであっても、OOM Killerさんの気が済むまで無差別に鏖。
OOM killerさんの取り立ての仕方があまりにも厳しすぎるので、最近はOOM reaperさんが頑張って仲介してくれてるが焼け石に水な上に、Androidで普通に使われてるようなカーネルバージョンではそもそも存在してない。
つまり要するにあれだ、メモリの連続性よりも空きメモリの方を心配しとけってこった。 >>>>デフラグ厨
Re: (スコア:0)
| 彡⌒ミ
\ (´・ω・`)またHugeの話してる・・・
(| |)::::
(γ /:::::::
し \:::
\
Re: (スコア:0)
お前は Huge じゃなくて Hage だろう……。
Re: (スコア:0)
えーっと、HugeTLB / Memory compaction / Page migration って、RAMの断片化には関係してるけど、
内蔵ストレージの断片化とは何の関係もないでしょ?
もしかして高度なギャグかなにか?
Re: (スコア:0)
長すぎて読む気が起きない、すごいな
Re: (スコア:0)
よく見ろ、これは吉野屋のコピペだ
# 違う
Re: (スコア:0)
HugeTLBってソフトページフォルトを削減するだけだから、余り極端な高速化にはつながらない上に高速化出来るケースが限定される技術だったと思うのだけど。
そもそもストレージの断片化と仮想メモリの断片化は全く別物……
HugeTLBが実装上ファイルシステムを使っているって程度か。
Re: (スコア:0)
てかAndroidを怪しいアプリ以外でデフラグする方法ってあるの?
メーカー側ならアンドロイドに手を入れればいいだろ
Re: (スコア:0)
バカは自分をバカだと理解できないところが最大の問題。
Re: (スコア:0)
断片化が悪いって言ってるの?