私は今日、Phoronixで、Linuxカーネルに200行のパッチがあり、デスクトップの応答性が劇的に向上することを読みました。
Ubuntuユーザーは、サポートされている方法でこれをどのように取得できますか？
私は今日、Phoronixで、Linuxカーネルに200行のパッチがあり、デスクトップの応答性が劇的に向上することを読みました。
Ubuntuユーザーは、サポートされている方法でこれをどのように取得できますか？
回答:
この特定のパッチに関する議論は、Ubuntu kernel-teamメーリングリストで行われました。
https://lists.ubuntu.com/archives/kernel-team/2010-November/013498.html
しかし、パッチをUbuntuカーネルに組み込むための最善の方法について、さらに一般的に詳しく説明してみましょう...
まず、Ubuntuカーネルチームに推奨されるポリシーであり、Ubuntuカーネルにプルされる前にアップストリームにパッチを提出して受け入れます。ツリー外のパッチを維持しなければならないのは、Ubuntu Kernel Teamにとって大きなメンテナンス負担です。さらに、パッチがカーネルコミュニティ全体に利益をもたらす場合は、最初にアップストリームに行く必要があります。
パッチがアップストリームで受け入れられると、最終的にはUbuntuカーネルに自動的に反映されます。必要に応じてチェリーピックまたはプルリクエストを行うこともできます。詳細については、KernelPatchesページを参照してください。
パッチを以前のUbuntuリリースにSRU（安定リリース更新）として適用する必要がある場合は、対応するアップストリームの安定した2.6.xyツリーにパッチを承認するのが最善です。通常のカーネルSRUプロセスの一環として、アップストリームの最新の安定したカーネルにリベースし続けています。したがって、最終的に再びパッチを自動的に取得します。
lkmlスレッドを読んだばかりで、Ubuntuにパッチを適用することについてではありませんが、いくつかの情報を提供できることを願っています。リンクされたUbuntuリストの投稿にあるように、とにかく2.6.38になるでしょう。
パッチは、TTYに基づいてプロセスを自動的にグループ化します。lkmlには多くの議論/議論があり、これは通常のデスクトップの使用には関係ないことを意味し、対話型アプリケーションには違いがないことを意味します。テストケースはすべて、「ターミナルからCPU集中型タスクを開始し、別のタスクの応答性を確認する」ことに基づいています。たとえば、カーネルをコンパイルしてビデオを視聴しようとします。
良くないというわけではありませんが、TTYに接続されたCPU集中タスクを実行しない場合、一般的な「デスクトップの応答性が桁違いに向上する」タイプの見出しは誤解を招く可能性があります。もちろん私は間違っているかもしれません！
bashスクリプトに追加し、すべてのユーザーがcgroupを作成できるようにすることで、非常に類似した結果を達成する方法についての言及がいくつかありました。これは、現在のUbuntuカーネルでcgroupが有効になっている場合にのみ機能します。関連する投稿は次のとおりです。
明らかにこれは質問に答えているわけではありませんが、パッチが希望どおりに魔法的であるかどうかを判断するために使用できます。
Ubuntuユーザーは、サポートされている方法でこれをどのように取得できますか？
強調鉱山。サポートされている方法で入手する唯一の方法は、UbuntuがUbuntuカーネルにプルするのを待つことです。これは実際にカーネルメーリングリストに登録されたばかりなので、すべてのテストがかなり逸話的なレベルに達するまで新鮮であり、大量展開の準備が整うまでにはしばらく時間がかかると思います。
次のリリースと長い時間の間のどこかが、私の無知な推測でしょう。
しかし、あなたが大きな男の子（または女の子）で、物事がうまくいかない場合（つまり、grubの使用方法を知っている場合）壊れたカーネルに対処できる場合は、独自のカーネルにパッチを適用してコンパイルできます。
パッチをダウンロードします。さまざまなバージョンがありますが、最高のものは別のユーザーによって以下に投稿されました：http : //pavlinux.ru/krnl/sched_autogroup-2.6.36.patch.bz2
パッチの対象となるバージョンのカーネルソースをダウンロードします。この場合2.6.36。kernel.orgからバニラ（つまり、Ubuntuカーネルチームによって変更されていないオリジナル）カーネルソースを取得し、それを抽出できます。
パッチをどこかに保存しcdて、カーネルソースディレクトリに移動して実行します：（これにpatch -p1 < /path/to/patchはpatchパッケージが必要です...これはbuild-essentialデフォルトでインストールされていない場合の一部と思います）
そして、残りの「昔ながらの」ビルドプロセスを続行します... Ubuntu / Debian認定のカーネルソースを対象としているので、新しいメソッドは気にしません...さらに、古い方法は簡単に思えます（私に）。
カーネルの構築は難しくありませんが、受け入れられたパスから離れすぎている場合は混乱させることができます。そして、物事がうまくいかない場合、公式のサポートは受けられません。
あるいは、パッチが組み込まれた状態で（または少なくともソースツリーに次のリリースを待っている状態で）カーネルが次々と出現しています。
注：これらのカーネル（およびおそらく他のカーネルも）は、カーネルを実行するUbuntuの方法とは多少異なります。（私がLiquorixに移動したときのように）CPU周波数スケーリングが機能しなくなったり、サスペンドが壊れたりすることがあります。通常、修正と回避策がありますが、AskUbuntuやその他のUbuntuコミュニティからサポートが得られない可能性があります。すべてのカーネルをチェックできないからです。
RedHat開発者がメーリングリストに投稿した単純な「ハック」を使用できます。これは、同じことをするためにカーネルにパッチを適用する必要がありません。ここでそれについて読む：すぐに使用できる「驚異的な200行のカーネルパッチ」の代替
2011-01-18現在、Linux 2.6.38-rc1には上記のパッチが含まれています。
関連するPhoronixのニュースとLinusの投稿を参照してください。
2011-01-29現在、Natty NarwhalのデイリービルドにはLinux 2.6.38が付属しています。
そのため、現在2つのソリューションがあります。