アカウント名:
パスワード:
なんでしないの
断片化が悪いとは言ってるけど、速度低下を防ぐ技術=デフラグしてるよ!とは言ってないと思うけど。
てか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が実装上ファイルシステムを使っているって程度か。
メーカー側ならアンドロイドに手を入れればいいだろ
バカは自分をバカだと理解できないところが最大の問題。
断片化が悪いって言ってるの?
「内蔵ストレージの最適化」ですね。これスマホの場合(パソコンでもそうですが)不要なファイルの削除のことです。
パソコンと違って中身いじったりしにくいんだから、キャッシュやテンポラリファイルや、ダウンロードして実行してもう終わったファイルなんかは、さっさと削除して欲しいもの。
自分で削除すりゃ良い?そりゃここの住人ならね・・・
だれか粉砕バットもってこーい!
# せめてTrimと言ってくれよ
フラッシュメモリーでデフラグしてるって言ったら理解・納得する人より非難する人の方が多いと思うね
少なくとも昔のデバイスでは、フラッシュストレージをwindowsから最適化したら早くなったっていってる。書き換え回数というデメリットがあっても早いほうが良いでしょ。どうせ二年で買い換える機械だ。
勝手にやらずに、ユーザーの操作でデフラグできる機能ぐらいつけてもバチは当たらない。
>どうせ二年で買い換える機械だ。そして「僅か3年程度で壊れるものを売るなんて」から、「自分の利益の為にXpを止めるとはケシカラン」とかなるんですね。
フラッシュメモリーは確かに原理上断片化に強い。といっても限度がある。特にスマートフォンに搭載されるフラッシュメモリーは低速なので長期間使うなら年に一回くらいはやったほうがいいだろう。極端な断片化が起きるとフラッシュメモリー上のデータの位置を処理するだけで時間がかかるし。ウェアレベリングのついでに断片化の解消も多少やりますし。そもそもスマホってウェアレベリングすらやってない気がする。
今のスマホの内蔵ストレージって結局eMMC組み込んであるわけで、eMMC内部でウェアレベリングしてあればスマホ自体がそこ考える必要はないだろうね。
というより、ウェアレベリングって、その個々のブロックの書き換え回数を管理しなければならないのでOSより上のレベルじゃ手出しできないんじゃない?
OSでも手を出せるかどうか微妙なレイヤだよな……やってもウェアレベリングがタコで長期アクセスしないと揮発する可能性があるから同一内容上書きで強制的に再書き換えを誘発程度だったりしそう。
Android 4.3でTrimに対応してるからやってんじゃね
素人の想像だとメリットよりデメリットの方が大きいからじゃないかなあ。
HDDがデフラグをするとアクセスが速くなるのは、シーケンシャルアクセスは速いけど、ランダムアクセスはとても遅いから。ランダムアクセスが遅いのは、読み込みに使うヘッドを読みたい場所に移動するのに時間がかかるから。だからシーケンシャルにアクセスできるように並び替えてあげるのは有効。
フラッシュメモリはランダムアクセスが速いので、HDDほどデフラグの効果はないし、仮にデフラグをしても、本当に連続して書かれるかはわからない。フラッシュメモリは書くほど寿命が減るので、同じア
> フラッシュメモリは書き込み回数によって速度低下しません。書き込み回数によってそのブロックが劣化してデータ損傷率が上がるだけです。なので同じ場所に何度も書くことが無いよう、通常はウェアレベリングを行います。これは書き換え回数の少ないブロックを別のブロックにコピーしてそこを書き込み先として使うなど、書き換えの行われていない場所を積極的に使用して劣化が一部に集中しないよう拡散させています。
フラッシュメモリの遅さは、どんな小さな書き換えでも「書き換え対象ブロックの未変更領域の読み込み」「書き込み対象ブロックの消去処理」「書き込み対象ブロック全体
円盤とは事情が違う円盤だと外側のほうが速度が早くなるからそちらにデータを寄せたくなるしヘッドの移動距離減らしたいから昔のOSだとどうしてもデータが混み合っていて更新が繰り返されると断片化しやすいSSDの場合は場所関係ないから広ければデータをばらしておけるしデータを更新するときはまとめて広いところに書き込めば断片化しないむしろ均等に使わないと寿命を縮めるその辺のアルゴリズムやツリー構造が高速化の鍵になる今時のFSなら広ければ広いほど快適に使える金に糸目をつけないならTBも見えてくる4K動画もため放題!金使うならRAMよりストレージなのは間違いないと思う
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
デフラグすりゃいいじゃん (スコア: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)
断片化が悪いって言ってるの?
Re: (スコア:0)
「内蔵ストレージの最適化」ですね。
これスマホの場合(パソコンでもそうですが)不要なファイルの削除のことです。
パソコンと違って中身いじったりしにくいんだから、
キャッシュやテンポラリファイルや、ダウンロードして実行してもう終わったファイルなんかは、さっさと削除して欲しいもの。
自分で削除すりゃ良い?そりゃここの住人ならね・・・
Re:デフラグすりゃいいじゃん (スコア:1)
「内蔵ストレージの最適化」ですね。
これスマホの場合(パソコンでもそうですが)不要なファイルの削除のことです。
だれか粉砕バットもってこーい!
# せめてTrimと言ってくれよ
Re: (スコア:0)
フラッシュメモリーでデフラグしてるって言ったら理解・納得する人より非難する人の方が多いと思うね
Re: (スコア:0)
少なくとも昔のデバイスでは、フラッシュストレージをwindowsから最適化したら早くなったっていってる。
書き換え回数というデメリットがあっても早いほうが良いでしょ。どうせ二年で買い換える機械だ。
勝手にやらずに、ユーザーの操作でデフラグできる機能ぐらいつけてもバチは当たらない。
Re: (スコア:0)
>どうせ二年で買い換える機械だ。
そして「僅か3年程度で壊れるものを売るなんて」から、「自分の利益の為にXpを止めるとはケシカラン」とかなるんですね。
Re: (スコア:0)
フラッシュメモリーは確かに原理上断片化に強い。といっても限度がある。
特にスマートフォンに搭載されるフラッシュメモリーは低速なので長期間使うなら年に一回くらいはやったほうがいいだろう。
極端な断片化が起きるとフラッシュメモリー上のデータの位置を処理するだけで時間がかかるし。
ウェアレベリングのついでに断片化の解消も多少やりますし。
そもそもスマホってウェアレベリングすらやってない気がする。
Re: (スコア:0)
今のスマホの内蔵ストレージって結局eMMC組み込んであるわけで、eMMC内部でウェアレベリングしてあればスマホ自体がそこ考える必要はないだろうね。
Re: (スコア:0)
というより、ウェアレベリングって、その個々のブロックの書き換え回数を管理しなければならないのでOSより上のレベルじゃ手出しできないんじゃない?
Re: (スコア:0)
OSでも手を出せるかどうか微妙なレイヤだよな……
やってもウェアレベリングがタコで長期アクセスしないと揮発する可能性があるから同一内容上書きで強制的に再書き換えを誘発程度だったりしそう。
Re: (スコア:0)
Android 4.3でTrimに対応してるからやってんじゃね
Re: (スコア:0)
素人の想像だとメリットよりデメリットの方が大きいからじゃないかなあ。
HDDがデフラグをするとアクセスが速くなるのは、シーケンシャルアクセスは速いけど、ランダムアクセスはとても遅いから。
ランダムアクセスが遅いのは、読み込みに使うヘッドを読みたい場所に移動するのに時間がかかるから。
だからシーケンシャルにアクセスできるように並び替えてあげるのは有効。
フラッシュメモリはランダムアクセスが速いので、HDDほどデフラグの効果はないし、仮にデフラグをしても、本当に連続して書かれるかはわからない。
フラッシュメモリは書くほど寿命が減るので、同じア
Re: (スコア:0)
> フラッシュメモリは書き込み回数によって速度低下
しません。
書き込み回数によってそのブロックが劣化してデータ損傷率が上がるだけです。
なので同じ場所に何度も書くことが無いよう、通常はウェアレベリングを行います。
これは書き換え回数の少ないブロックを別のブロックにコピーしてそこを書き込み先として使うなど、
書き換えの行われていない場所を積極的に使用して劣化が一部に集中しないよう拡散させています。
フラッシュメモリの遅さは、どんな小さな書き換えでも
「書き換え対象ブロックの未変更領域の読み込み」
「書き込み対象ブロックの消去処理」
「書き込み対象ブロック全体
Re: (スコア:0)
円盤とは事情が違う
円盤だと外側のほうが速度が早くなるから
そちらにデータを寄せたくなるし
ヘッドの移動距離減らしたいから
昔のOSだとどうしてもデータが混み合っていて
更新が繰り返されると断片化しやすい
SSDの場合は場所関係ないから
広ければデータをばらしておけるし
データを更新するときはまとめて広いところに書き込めば断片化しない
むしろ均等に使わないと寿命を縮める
その辺のアルゴリズムやツリー構造が高速化の鍵になる
今時のFSなら広ければ広いほど快適に使える
金に糸目をつけないならTBも見えてくる
4K動画もため放題!
金使うならRAMよりストレージなのは間違いないと思う